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Advanced Report Writing Techniques in VAX Datatrieve 

Lynn D. Duncan, Oak Ridge National Laboratory operated by Martin Marietta Energy Systems, Inc., Oak 
Ridge, Tennessee 37831 


1.1 Review of Report Writer 

1.1.1 Functions 

The DTR Report Writer produces formatted, paginated reports. It picks up where PRINT and SUM leave 
off. It provides an easy way to create both simple and complex reports. Because of the many defaults, a 
novice can become productive in very little time. But users often find they need something different from 
the standard default formats. When that occurs, the user may take control of many aspects of the Report 
Writer including: 

• sort the records into desired order 

• select the fields to be printed 

• order the fields to be printed 

• format the fields to be printed 

• print statistical information based on the data 

• specify control groups 

• direct the report to a device or file 

• format the report title and column headings 

• control pagination 


1.1.2 Statements 

The DTR Report Writer consists of only five statements; that is all. 


REPORT 

PRINT 

AT 

SET 

END-REPORT 


begins the definition of a report; required 

defines the content and format of all detail lines; optional, no more than 1 
allowed, at least 1 PRINT or AT required 

defines the location, content and format of header and summary lines; 
optional 

specifies report parameters; optional 
terminates report definition; required 


1.2 Examples 

1.2.1 A Simple Report 


DTR> REPORT YACHTS 
RW> PRINT BOAT 
RW> END-REPORT 


In the above report specification, all the defaults are in effect. The only thing specified is the data to be 
reported. Included below is the first portion of the report created by those three statements. Notice that 
the date and page numbers are automatically included on each page, that the data is spread out to fill the 
page evenly, and that the column headers are printed at the top of each page. The PRINT statement won’t 
do that for you. 
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4-Sep-84 
Page 1 


LENGTH 


MANUFACTURER 

MODEL 

RIG 

OVER 

ALL 

WEIGHT 

BEAM 

PRICE 

ALBERG 

37 MK II 

KETCH 

37 

20,000 

12 

$36,951 

ALBIN 

79 

SLOOP 

26 

4,200 

10 

$17,900 

ALBIN 

BALLAD 

SLOOP 

30 

7,276 

10 

$27,500 

ALBIN 

VEGA 

SLOOP 

27 

5,070 

08 

$18,600 

AMERICAN 

26 

SLOOP 

26 

4,000 

08 

$9,895 

AMERICAN 

26-MS 

MS 

26 

5,500 

08 

$18,895 

BAYFIELD 

30/32 

SLOOP 

32 

9,500 

10 

$32,875 

BLOCK I. 

40 

SLOOP 

39 

18,500 

12 


BOMBAY 

CLIPPER 

SLOOP 

31 

9,400 

11 

$23,950 

BUCCANEER 

270 

SLOOP 

27 

5,000 

08 


BUCCANEER 

320 

SLOOP 

32 

12,500 

10 


C&C 

CORVETTE 

SLOOP 

31 

8,650 

09 


CABOT 

36 

SLOOP 

36 

15,000 

12 



1.2.2 A Simple Report - with control breaks and statistics 

DTR> REPORT YACHTS WITH PRICE GT 0 SORTED BY BUILDER, DESC PRICE 
RU> SET REPORT-NAME = "YACHT PRICE REPORT - BY BUILDER" 

RW> AT TOP OF BUILDER PRINT BUILDER 
RW> PRINT MODEL, RIG, PRICE 

RW> AT BOTTOM OF BUILDER PRINT COL 40, "NUMBER OF MODELS:", COUNT, 

[Looking for next element in list] 

RU> SKIP 
RU> END-REPORT 

In this report specification, a few more Report Writer features are used. A record selection expression is 
included in the REPORT statement which selects and orders the records to be printed. A report title is 
assigned. Only selected fields are printed in the detail lines. Control breaks are used to print summary 
information. Some format control is done with COL and SKIP but this is still a basic, standard DTR 
report. 


Included below is the first portion of the report created by the preceding RW statements. 



YACHT PRICE REPORT - BY BUILDER 
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MANUFACTURER 

MODEL 


RIG 

PRICE 


ALBERG 

37 MK II 


KETCH 

$36,951 



NUMBER 

OF 

MODELS: 

1 


ALBIN 

BALLAD 


SLOOP 

$27,500 



VEGA 


SLOOP 

$18,600 



79 


SLOOP 

$17,900 



NUMBER 

OF 

MODELS: 

3 


AMERICAN 

26-MS 


MS 

$18,895 



26 


SLOOP 

$9,895 
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NUMBER OF MODELS: 


2 


BAYFIELD 


30/32 SLOOP 

NUMBER OF MODELS: 


$32,875 

1 


1.3 Saving the report specification 

ALWAYS, ALWAYS, ALWAYS save your report specification in a procedure or command file. In creating 
reports, it generally takes several passes to get the report looking right. Even if you think you’ll never use 
a particular report again, you probably will and it is very handy to have old report procedures to cannibalize 
when creating new ones. 

There have been several methods suggested for typing in the report specification and getting it into a 
procedure. The following method allows DTR to perform syntax checking line by line as each is typed in 
and still gets the entire report into a procedure without retyping. 


1. ) Create the report interactively. 

DTR> REPORT YACHTS .... 

RW> .... any valid report statements ... 

RW> END-REPORT 

2. ) After viewing the report, edit your last command. 

(Your last command is the entire report specification.) 

DTR> EDIT (with NO object) 

3. ) While in EDT, add 1 line at the beginning and end of the report. 

Insert "REDEFINE PROCEDURE report-name" as first line. 

Insert "END PROCEDURE" as last line. 

4. ) EXIT from EDT, and a procedure containing the report specification is automatically defined in the 

dictionary. 

Important Note: This also works if you encounter an error before completion of the report specification. 
When you type in EDIT the entire last command, beginning at REPORT will be in the buffer for editing. 
At that point, you can correct the error, insert the REDEFINE PROCEDURE and END PROCEDURE 
commands and insert the remainder of your report statements. Once the report is defined as a procedure, 
you can invoke the report with -.report-name and edit it repeatedly until it is just what you want. 

2.0 Using control groups 


2.1 Establishing Sort Order 

In order to use control groups, the record stream for the report must be in some sorted order. Establish 
sorted order in any of 3 ways: 

1. ) report on a sorted collection 

2. ) use SORTED BY in the REPORT statement 

3. ) use the primary key of an indexed file 


2.2 Using Statistical Operators 

DTR will summarize the data in each control group, and for the entire report. Establish groups by breaking 
data with AT TOP/BOTTOM statements. These must refer to a field that was in the sort key. They may 
contain any DTR statistical operators but choice of placement can produce different results, as in the 
following example: 
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DTR> FIND YACHTS WITH BUILDER CONT 'AL' SORTED BY BUILDER 
[15 records found] 

RW> REPORT ON EX.RPT 

RW> AT TOP OF BUILDER PRINT COL 1, BUILDER, COL 15, COUNT ("NUMBER") - 
RW> USING ZZ9 , COL 26, AVERAGE BEAM ("AVG"/"BEAM") 

RW> PRINT MODEL, RIG, BEAM, LOA 

RW> AT BOTTOM OF BUILDER PRINT COL 15, COUNT USING ZZ9 , COL 26, 

RW> AVERAGE BEAM, SKIP 
RW> END-REPORT 


Notice that the values for COUNT and AVERAGE BEAM printed in the sample output below are the 
same in every header (AT TOP OF BUILDER) line. That is because these values are computed from the 
entire collection. The values in the summary (AT BOTTOM OF BUILDER) lines are different because they 
are based on the groups by BUILDER. Also interesting is the fact that when no column specifiers were 
used, there were 2 columns for COUNT and 2 for AVERAGE BEAM. You might suspect that DTR 
"knows" these values do not represent the same things. 

5-Sep-84 

Page 1 

LENGTH 




AVG 




OVER 

MANUFACTURER 

NUMBER 

BEAM 

MODEL 

RIG 

BEAM 

ALL 

ALBERG 

15 

09 

37 MK II 

KETCH 

12 

37 


1 

12 





ALBIN 

15 

09 

79 

SLOOP 

10 

26 




BALLAD 

SLOOP 

10 

30 




VEGA 

SLOOP 

08 

27 


3 

09 





CAL 

15 

09 

2-27 

SLOOP 

09 

27 




2-34 

SLOOP 

10 

33 




29 

SLOOP 

09 

29 




3-30 

SLOOP 

10 

30 




35 

SLOOP 

11 

35 


5 

09 






2.3 Multiple Level Breaks and Totals 

Multiple AT TOP/BOTTOM statements can be included in the report specification, as in the example 
below, to produce multiple levels of subtotals and grand totals. 

DTR> SHOW LOA-REPORT 
DELETE LOA_REPORT; 

DEFINE PROCEDURE LOAREPORT 

REPORT FIRST 30 YACHTS WITH PRICE > 0 AND LOA BT 25 AND 30 SORTED 
BY LOA, BEAM ON TT: 

SET REPORT_NAME="MY VERY OWN LISTING"/"OF"/"INTERESTING SAILBOATS"/ 

"(BY LENGTH AND BEAM)" 

!0K to set multiple elements in 1 SET statement 
SET LINES PAGE=55, C0LUMNS_PAGE=72 
AT TOP 0F“L0A PRINT LOA ("LENGTH") 
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AT TOP OF BEAM PRINT BEAM 
PRINT TYPE, RIG, DISP, PRICE 

AT BOTTOM OF BEAM PRINT COL 25, "*** Average for beam ***", 

AVERAGE DISP, AVERAGE PRICE 

AT BOTTOM OF LOA PRINT SKIP, COL 25, "*** Average for LOA ***", 

AVERAGE DISP, AVERAGE PRICE 

AT BOTTOM OF REPORT PRINT SKIP, COL 25, "*** REPORT AVERAGES ***", 

AVERAGE DISP, AVERAGE PRICE 
AT BOTTOM OF PAGE PRINT SKIP 3, COL 20, 

"""ANOTHER SERVICE OF QUERY ENTERPRISES""" 

ENDREPORT 
END-PROCEDURE 

The above report specification produces the report which is included below. The dashed line indicates that 
a portion of the report has been omitted to save space. 

MY VERY OWN LISTING 
OF 

INTERESTING SAILBOATS 
(BY LENGTH AND BEAM) 


LENGTH BEAM 

MANUFACTURER MODEL 

RIG 

WEIGHT 

PRICE 

25 







07 

CAPE DORY 

25 


SLOOP 

4,000 

$8,995 


SALT 

19 


SLOOP 

2,600 

$6,590 


kkk 

Average 

for beam 

kkk 

3,300 

$7,793 

12 

IRWIN 

25 


SLOOP 

5,400 

$10,950 


"kick 

Average 

for beam 

kkk 

5,400 

$10,950 


kkk 

Average 

for LOA *** 

4,000 

$8,845 

30 







09 

GRAMPIAN 

30 


SLOOP 

8,600 

$17,775 


PEARSON 

30 


SLOOP 

8,320 

$12,000 


*** Average 

for beau 

1 kkk 

8,460 

$14,888 

10 

IRWIN 

30 


SLOOP 

10,000 

$19,950 


HUNTER 

30 


SLOOP 

9,500 

$21,500 


ISLANDER 

30 


SLOOP 

8,600 

$20,990 


ALBIN 

BALLAD 

SLOOP 

7,276 

$27,500 


*** Average for beam *** 8,844 $22,485 


*** Average for LOA *** 8,716 $19,953 

*** REPORT AVERAGES *** 6,462 $19,029 

"ANOTHER SERVICE OF QUERY ENTERPRISES" 

3.0 Reporting Information NOT in the Domain 

Reports can include information that is not contained in the source domain. In addition to field values, 
statistics and literals, which have already been demonstrated. RW can print calculated values, declared 
variables, values from tables, and values from additional domains. 


19-Sep-1984 
Page 1 
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3.1 Calculated Values 

One way to report data that is not in the domain is to include calculations within the PRINT stateme 
itself, as shown below. 

DTR> REPORT YACHTS WITH RIG = "KETCH" AND LOA GT 36 AND PRICE NE 0 - 
RW> SORTED BY LOA, BEAM, PRICE 

RW> SET REPORT-NAME = "PRICE PER FOOT REP0RT"/"0N BIG KETCHES" 

RW> PRINT TYPE, BEAM, PRICE, LOA, PRICE/LOA ("PRICE"/"PER"/"F00T") - 
RW> USING $$,$$9 

RW> AT BOTTOM OF REPORT PRINT SKIP, COL 7, "NUMBER OF BOATS:", - 
RW> COL 25, COUNT (-) USING 9 , SKIP, COL 25, "AVERAGE PRICE:", - 
RW> AVERAGE PRICE (-) USING $$$$,$$9 , COL 40, 

RW> "AVERAGE PRICE PER FOOT:", AVERAGE (PRICE/LOA) (-) - 

RW> USING $$$$,$$9 

RW> END-REPORT 


Note that a column header and edit-string is supplied in each statement that calculates and prints t. 
value. COL specifiers are used to align the columns of the detail and summary lines. The resulting rep< 
is displayed below. 

PRICE PER FOOT REPORT 4-Sep-84 

ON BIG KETCHES Page 1 


LENGTH PRICE 

OVER PER 


MANUFACTURER 

MODEL 

BEAM 

PRICE 

ALL 

FOOT 

IRWIN 

37 MARK II 

11 

$36,950 

37 

$998 

NORTHERN 

37 

11 

$50,000 

37 

$1,351 

ALBERG 

37 MK II 

12 

$36,951 

37 

$998 

GULFSTAR 

41 

12 

$41,350 

41 

$1,008 

CHALLENGER 

41 

13 

$51,228 

41 

$1,249 

ISLANDER 

FREEPORT 

13 

$54,970 

41 

$1,340 

PEARSON 

419 

13 

$65,000 

42 

$1,547 

OLYMPIC 

ADVENTURE 

13 

$80,500 

42 

$1,916 

NUMBER OF BOATS 

: 8 

AVERAGE 

PRICE: 

AVERAGE 

$52,118 
PRICE PER 

FOOT: 

$1,301 


3.2 Variables 

Another way to accomplish the same thing is to declare a variable before invoking the Report Writer 

DTR> DECLARE PRICE-PER-FOOT COMPUTED BY PRICE/LOA QUERY-HEADER IS - 
CON> "PRICE"/"PER"/"FOOT" EDIT-STRING IS $$$$,$$9. 

DTR> REPORT YACHTS WITH RIG = "KETCH" AND LOA GT 36 AND PRICE NE 0 - 
RW> SORTED BY LOA, BEAM, PRICE 

RW> SET REPORT-NAME = "PRICE PER FOOT REPORT"/"ON BIG KETCHES" 

RW> PRINT TYPE, BEAM, PRICE, LOA, PRICE-PER-FOOT . 

RW> AT BOTTOM OF REPORT PRINT SKIP, COL 6, "NUMBER OF BOATS:", 

RW> COL 25, COUNT (-) USING 9 , SKIP, COL 25, "AVERAGE PRICE:", 

RW> AVERAGE PRICE (-) USING $$$$,$$9 , COL 42, 

RW> "AVERAGE PRICE PER FOOT:", AVERAGE PRICE-PER-FOOT (-) USING 

RW> $$$$,$$9 

RW> END-REPORT 
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Notice here that the column header and edit strings are defined in the DECLARE command and are not 
required in any of the RW statements. It may be only a small savings in keystrokes in this example but 
could be significant if there were several levels of sub-totals. Again, COL specifiers were used to align the 
detail and summary columns. 




PRICE PER 

FOOT REPORT 


4-Sep 



ON BIG 

KETCHES 


Page 





LENGTH 

PRICE 





OVER 

PER 

MANUFACTURER 

MODEL 

BEAM 

PRICE 

ALL 

FOOT 

IRWIN 

37 MARK II 

11 

$36,950 

37 

$998 

NORTHERN 

37 

11 

$50,000 

37 

$1,351 

ALBERG 

37 MK II 

12 

$36,951 

37 

$998 

GULFSTAR 

41 

12 

$41,350 

41 

$1,008 

CHALLENGER 

41 

13 

$51,228 

41 

$1,249 

ISLANDER 

FREEPORT 

13 

$54,970 

41 

$1,340 

PEARSON 

419 

13 

$65,000 

42 

$1,547 

OLYMPIC 

ADVENTURE 

13 

$80,500 

42 

$1,916 


NUMBER OF BOATS: 8 

AVERAGE PRICE: $52,118 

AVERAGE PRICE PER FOOT: $1,301 


3.3 Tables 

One more way to report data not in the domain is to use the VIA clause to reference information in tables. 
The RW PRINT works just like a normal PRINT statement in this manner. 

The definition of the RIG table is included below for reference. 

DTR> DEFINE TABLE RIG_TABLE 

DFN> QUERY_HEADER IS "RIG"/"DESCRIPTION" 

DFN> EDITSTRING IS X(15) 

DFN> "SLOOP" : "ONE MAST" 

DFN> "KETCH" : "TWO MASTS" 

DFN> "YAWL" : "TWO MASTS" 

DFN> "M/S" : "SAILS AND MOTOR" 

DFN> ELSE "SOMETHING ELSE" 

DFN> END_TABLE 

The following report specification references the RIG table to get information that does not exist in the 
domain. 

DTR> REPORT YACHTS WITH PRICE > 0 SORTED BY DESC PRICE ON VIA.RPT 
RW> PRINT COL 1, BUILDER, COL 20, RIG VIA RIG_TABLE USING X(16), 

[Looking for next element in list] 

RW> BEAM, PRICE 
RW> END_REPORT 

The three RW statements above produce a report which starts out like the following example. The remain¬ 
der of the report has been omitted to save space. 
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MANUFACTURER 

RIG 

DESCRIPTION 

BEAM 

ll-Sep-1984 
Page 1 

PRICE 

OLYMPIC 

TWO MASTS 

13 

$80,500 

PEARSON 

ONE MAST 

12 

$79,000 

PEARSON 

TWO MASTS 

13 

$65,000 

ISLANDER 

TWO MASTS 

13 

$54,970 

CHALLENGER 

TWO MASTS 

13 

$51,228 

NORTHERN 

TWO MASTS 

11 

$50,000 

PEARSON 

ONE MAST 

10 

$49,500 

COLUMBIA 

ONE MAST 

11 

$48,490 

PEARSON 

ONE MAST 

11 

$45,999 

PEARSON 

ONE MAST 

08 

$45,999 

PEARSON 

ONE MAST 

09 

$45,890 


3.4 Other Domains 

By using CROSS in the REPORT statement, information from other domains can be made available. All 
that is required is a field in both domains with a common value so that the records can be linked together. 
The definition of the OWNER record below shows us that there is a common field, TYPE, in OWNERS 
and YACHTS. 

DTR> SHOW OWNER-RECORD 
DEFINE RECORD OWNER_RECORD 
01 OWNER. 

03 NAME PIC X(10) QUERYHEADER IS "OWNER"/"NAME" 

EDITSTRING IS X(5). 

03 B0AT_NAME PIC X(17) QUERY_HEADER IS "BOAT NAME". 

03 TYPE. 

06 BUILDER PIC X(10). 

06 MODEL PIC X(10). 


The following report specification shows how to use CROSS and the common field to make data available 
from multiple domains. 

DTR> SO OWNER-REPORT 
DELETE 0WNER_REP0RT; 

DEFINE PROCEDURE 0WNER_REP0RT 
READY OWNERS, YACHTS 

REPORT OWNERS CROSS YACHTS OVER TYPE SORTED BY TYPE, B0AT_NAME 
SET REPORT_NAME = "Owners of Yachts'V'By Builder and Model" 

SET LINES_PAGE = 65, COLUMNS_PAGE = 75 
AT TOP OF TYPE PRINT COL 10, 

BUILDER||"'S"|||MODEL ("Builder/Model") USING X(15), 

PRICE ("Purchase Price") 

AT TOP OF B0AT_NAME PRINT B0AT_NAME ("Boat Names") 

PRINT NAME ("Owner's Names") 

AT BOTTOM OF BOAT_NAME PRINT COL 20, 

"Number of Owners (this boat):"||jCOUNT (-), SKIP 
AT BOTTOM OF TYPE PRINT COL 20, 

"Number of Owners (this type):"|||COUNT (-), SKIP 
!Use same EDIT_STRING for each item to guarantee alignment 
AT BOTTOM OF REPORT PRINT COL 20, "Total Number of Owners:", SPACE, 

COUNT (-) USING ZZZZ,ZZ9, COL 20, "Minimum Purchase Price:", 

SPACE, MIN PRICE (-) USING $$$$,$$9, 
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COL 20, "Maximum Purchase Price:", SPACE, 
MAX PRICE (-) USING $$$$,$$9 
END_REPORT 
END-PROCEDURE 


The beginning and end of the resulting report is summarized below. 

Owners of Yachts 
By Builder and Model 

Builder/Model Purchase Price Boat Names 

ALBIN'S VEGA $18,600 

DELIVERANCE 

Number of Owners (this boat): 1 

IMPULSE 

Number of Owners (this boat): 1 
Number of Owners (this type): 2 
C&C'S CORVETTE $25,000 

EGRET 


Number of Owners (this boat): 2 
Number of Owners (this type): 2 
RHODES'S SWIFTS $35,500 

STRIDER 

Number of Owners (this boat): 1 

Number of Owners (this type): 1 

Total Number of Owners: 11 

Minimum Purchase Price: $6,500 

Maximum Purchase Price: $54,730 

4.0 Using the CHOICE Value Expression 
4.1 Printing Different Detail Lines 

The RW allows only 1 PRINT statement which controls the printing of all the detail lines. At times there 
is a need to print different detail lines depending on the values of certain items. The CHOICE value 
expression provides the mechanism for doing that. As an example, the following report specification prints 
a notation which highlights the most expensive yachts and the bargains. 

DTR> REPORT YACHTS WITH LOA GT 30 AND BEAM GT 10 ON RANGES.RPT 
RW> SET REP0RT_NAME = "YACHT PRICE REPORT" 

RW> PRINT TYPE, PRICE, CHOICE 
RW> PRICE = 0 THEN "UNKNOWN" 

RW> (PRICE > 0 AND PRICE < 20000) THEN "BARGAIN" 


18-Sep-1984 
Page 1 

Owner's Names 


STEVE 


HUGH 


JIM 

ANN 


JOHN 
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RW> ELSE "EXPENSIVE" 

RW> END_CHOICE ("PRICE"/"RANGE") 

RW> AT BOTTOM OF REPORT PRINT SKIP, COL 26, 
[Looking for next list element] 

RW> "*** END OF PRICE REPORT ***" 

RW> END REPORT 


The first and last few lines of the resulting report are summarized below. 

YACHT PRICE REPORT 11-Sep L984 

Page 1 





PRICE 

MANUFACTURER 

MODEL 

PRICE 

RANGE 

ALBERG 

37 MK II 

$36,951 

EXPENSlVE 

BLOCK I. 

40 


UNKNOWN 

BOMBAY 

CLIPPER 

$23,950 

EXPENSIVE 

CABOT 

36 


UNKNOWN 

CAL 

35 


UNKMOWN 

CARIBBEAN 

35 

$37,850 

EXPENSIVE 

CHALLENGER 

32 

$31,835 

EXPENSIVE 

ROBERTS 

36 


UNKNOWN 

ROGGER FD 

M/S 


UNKNOWN 

WESTSAIL 

32 


UNKNOWN 


*** END OF PRICE REPORT "k'k'k 


4.2 CHOICE in Control Groups 

In addition to using the CHOICE value expression in the PRINT statement of the Report Writer, it can be 
used in a variable which serves as a control break. The field that the CHOICE is computed from must be 
used to order the record stream used for the report, as PRICE ami PRICE RANGE in the sample below 

DTR> DECLARE PRICE_RANGE COMPUTED BY CHOICE 
DTR> PRICE = 0 THEN "UNKNOWN" 

DTR> PRICE < 20000 THEN "BARGAIN" 

DTR> PRICE < 50000 THEN "MODERATE" 

DTR> ELSE "EXPENSIVE" 

DTR> END_CH0ICE 

DTR> EDIT_STRING IS X(9). 

DTR> REPORT YACHTS WITH RIG = "KETCH" SOP 1 ED BY PRICE ON KETCH.RPT 
RW> SET REP0RT_NAME - "KETCH PRICE RANGE REPORT" 

RW> AT TOP OF PRICE_RANGE PRINT PRICE_RANGE|||"PRICED KETCHES" (-) 

RW> PRINT TYPE, DISP, LOA, BEAM 

RW> AT BOTTOM OF PRICE_RANGE PRINT SFlP 

RW> AT BOTTOM OF REPORT PRINT SKIP, COL 26, 

[looking for next list element] 

RW> "*** END OF PRICE REPORT ***" 

RW> END_REPORT 

The following report provides the same types of information as the previous example, but using the 
CHOICE value expression to trigger the control breaks leads to a more readable report. 
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KETCH PRICE 

RANGE REPORT 


ll-0ct- 

-1984 


MANUFACTURER 

MODEL 

WEIGHT 

Page 1 

LENGTH 

OVER 

ALL 

BEAM 

UNKNOWN PRICED KETCHES 


PEARSON 

365 

17,700 

36 

11 


PEARSON 

419 

21,000 

42 

13 


FISHER 

37 

30,000 

37 

12 

BARGAIN PRICED KETCHES 


GRAMPIAN 

34 

12,000 

33 

10 


FISHER 

30 

14,500 

30 

09 

MODERATE PRICED KETCHES 


IRVIN 

37 MARK II 

20,000 

37 

11 


ALBERG 

37 MK II 

20,000 

37 

12 


I. TRADER 

37 

18,600 

36 

12 


GULFSTAR 

41 

22,000 

41 

12 

EXPENSIVE PRICED KETCHES 


NORTHERN 

37 

14,000 

37 

11 


CHALLENGER 

41 

26,700 

41 

13 


ISLANDER 

FREEPORT 

22,000 

41 

13 


OLYMPIC 

ADVENTURE 

24,250 

42 

13 


*** END OF PRICE REPORT *** 


5.0 Reporting Hierarchical Data 

Dealing with hierarchical data can be difficult in DTR and can get worse within RW. One of the easiest 
ways to deal with hierarchical data, using nested FORs, is not available in RW. The remaining options 
include using the CROSS clause in the RSE of the REPORT statement, using an inner print list, or 
issuing the SET SEARCH command before the REPORT statement. 

5.1 Retaining the Hierarchical Structure 

Of course, a report can be created with the hierarchy intact. This can be done by using the 01 group level 
field name in the PRINT statement. For reference, the FAMILY record definition is included below. Note 
that the 01 level group field is FAMILY. 

RECORD FAMILY_REC 
01 FAMILY. 

03 PARENTS. 

06 FATHER PIC X(10). 

06 MOTHER PIC X(10). 

03 NUMBERJCIDS PIC 99 EDIT_STRING IS Z9. 

03 KIDS OCCURS 0 TO 10 TIMES DEPENDING ON NUMBER_KIDS. 

06 EACH_KID. 

09 KID_NAME PIC X(10) QUERY_NAME IS KID. 

09 AGE PIC 99 EDIT STRING IS Z9. 


A simple report retaining the hierarchical structure of the data is included below. Note that the field 
FAMILY is included in the RW PRINT statement. An alternate statement to achieve the same results 
would be "PRINT PARENTS, NUMBERKIDS, KIDS", but "PRINT PARENTS, NUMBERKIDS, KID- 
NAME" results in an error 


DTR-12 



DTR> REPORT FAMILIES ON FAMILY.RPT 
RW> SET REPORT_NAME = "Family Report" 
RW> PRINT FAMILY 
RW> END REPORT 


The first portion of the resulting report follows. 


Family Report 16-Sep-1984 

Page 1 




NUMBER 

KID 


FATHER 

MOTHER 

KIDS 

NAME 

AGE 

JIM 

ANN 

2 

URSULA 

7 




RALPH 

3 

JIM 

LOUISE 

5 

ANNE 

31 




JIM 

29 




ELLEN 

26 




DAVID 

24 




ROBERT 

16 

JOHN 

JULIE 

2 

ANN 

29 




JEAN 

26 

JOHN 

ELLEN 

1 

CHRISTOPHR 

0 

ARNIE 

ANNE 

2 

SCOTT 

2 




BRIAN 

0 

SHEARMAN 

SARAH 

1 

DAVID 

0 

TOM 

ANNE 

2 

PATRICK 

4 




SUZIE 

6 


This report is fine if you want all the information in the domain and nothing extra. Unfortunately, that 
rarely is the case. 

5.2 Using CROSS in the REPORT statement 

The CROSS clause can be used to join the domain to the list, which essentially flattens the hierarchy. Be 
sure to use individual field names in the print list, as in the example below, instead of the group field 
FAMILY. Now the individual fields that were in the list are accessible for totals, 
etc. 


DTR> SHOW FLAT-FAM 
DELETE FLAT_FAM; 

DEFINE PROCEDURE FLAT_FAM 

REPORT FAMILIES CROSS KIDS SORTED BY PARENTS, AGE ON TT: 
SET REPORTJNAME = "Flat Family Report" 

AT TOP OF PARENTS PRINT COL 1, FATHER, COL 15, MOTHER 
AT BOTTOM OF PARENTS PRINT COL 52, 

COUNT ("Number"/"Of Kids") USING Z9, 

COL 62, TOTAL AGE ("Total"/"Age") USING ZZZ9, 

COL 72, AVERAGE AGE ("Avg"/"Age") USING Z9 
PRINT COL 30, KIDJJAME, COL 45, AGE 
END_REPORT 
END-PROCEDURE 


One feature of the CROSS demonstrated by the sample output below is that families with no children do 
not show up on the flat report. This may be a problem in certain applications. 
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Flat Family Report 



19-Sep-1984 







Page 1 



KID 


Number 

Total 

Avg 

FATHER 

MOTHER 

NAME 

AGE 

Of Kids 

Age 

Age 

ARNIE 

ANNE 

BRIAN 

0 






SCOTT 

2 

2 

2 

1 

BASIL 

MERIDETH 

WREN 

17 






JILL 

20 






JAY 

22 






ROBIN 

24 






BROOKS 

26 






BEAU 

28 

6 

137 

23 

EDWIN 

TRINITA 

SCOTT 

11 






ERIC 

16 

2 

27 

14 


5.3 Summary Info from Lists 

It is not always necessary to flatten the hierarchy to get at the individual fields that make up a list. In the 
following example "AT BOTTOM OF FATHER" is used to total values from the list fields in a single 
record. Although the TOTALs may seem redundant, they are required to make the 
report work. 

DTR> SHOW FAM-STATS 
DELETE FAM-STATS; 

DEFINE PROCEDURE FAM-STATS 

DECLARE T0T_AGE COMPUTED BY TOTAL AGE OF KIDS. 

IFamilies without kids can be included or excluded 
REPORT FIRST 5 FAMILIES WITH (NUMBER_KIDS NE 0) AND 
(NOT ANY KIDS WITH AGE = 0) SORTED BY FATHER, MOTHER ON *.WHERE 
SET REPORT_NAME = "Report of Kids and Ages" 

PRINT FAMILY 

AT BOTTOM OF FATHER PRINT "Family statistics:", 

TOTAL (T0T_AGE) ("Total"/"Age") USING ZZZ9, 

(TOTAL (T0T_AGE)) / (TOTAL NUMBER_KIDS) ("Aver"/"Age") USING ZZZ9, 

SKIP 

AT BOTTOM OF REPORT PRINT SKIP, "Report statistics:", 

TOTAL NUMBERJCIDS USING ZZZ9, 

TOTAL (T0T_AGE) USING Z999, 

(TOTAL (T0T_AGE)) / (TOTAL NUMBERJCIDS) USING ZZZ9 
END_REPORT 
END-PROCEDURE 

The resulting report, complete with accurate statistics, is included below. 
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Report 

of Kids and 

Ages 


18-Sep-1984 






Page 

1 



NUMBER 

KID 


Total 

Aver 

FATHER 

MOTHER 

KIDS 

NAME 

AGE 

Age 

Age 

BASIL 

MERIDETH 

6 

BEAU 

28 






BROOKS 

26 






ROBIN 

24 






JAY 

22 






WREN 

17 






JILL 

20 



Family statistics: 





137 

23 

EDWIN 

TRINITA 

2 

ERIC 

16 






SCOTT 

11 



Family statistics: 





27 

14 

GEORGE 

LOIS 

3 

JEFF 

23 






FRED 

26 






LAURA 

21 



Family statistics: 





70 

23 

HAROLD 

SARAH 

3 

CHARLIE 

31 






HAROLD 

35 






SARAH 

27 



Family statistics: 





93 

31 

JEROME 

RUTH 

4 

ERIC 

32 






CISSY 

24 






NANCY 

22 






MICHAEL 

20 



Family statistics: 





98 

25 

Report statistics: 


18 



425 

24 


6.0 Special Formatting 
6.1 Nonstandard Outputs 

The Report Writer can be used to create documents with nonstandard layouts and with very little data 
supplied from a domain. In the following example a domain with student names is used to create a set of 
diplomas. 

This example also shows how a cover page can be produced, use of prompting expressions, specialized date 
handling, and concatenation. 

DTR> DEFINE RECORD STUDENT_REC USING 
DFN> 01 STUDENT_NAME. 

DFN> 05 FIRST_NAME PIC X(10). 

DFN> 05 LAST_NAME PIC X(20). 

DFN> ; 

DTR> DEFINE PROCEDURE DIPLOMA 
DFN> READY STUDENTS 

DFN> !Format the ending day of class. 

DFN> DECLARE END DATE USAGE DATE. 
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DFN> DECLARE DAY_FORMAT PIC XX COMPUTED BY 
DFN> CHOICE 

DFN> FN$DAY(END_DATE) = 1 THEN "st" 

DFN> FN$DAY(END_DATE) =21 THEN "st" 

DFN> FN$DAY(END_DATE) =31 THEN "st" 

DFN> FN$DAY(END_DATE) = 2 THEN "nd" 

DFN> FN $ DAY(END_DATE) = 22 THEN "nd" 

DFN> FN$DAY(END_DATE) = 3 THEN "rd" 

DFN> FN$DAY(END_DATE) =23 THEN "rd" 

DFN> ELSE "th" 

DFN> END_CHOICE. 

DFN> [Declare other temp variables. 

DFN> DECLARE CLASS_LENGTH PIC 99. 

DFN> DECLARE INSTRUCTOR PIC X(30). 

DFN> DECLARE C0URSE_NAME PIC X(30). 

DFN> DECLARE STAR40 PIC X(40). 

DFN> DECLARE STAR80 PIC X(80). 

DFN> [Prompt for values 

DFN> END_DATE = *."date class ended" 

DFN> CLASS_LENGTH = *."number of class days" 

DFN> INSTRUCTOR = *."instructor (max. 30 chars)" 

DFN> COURSE_NAME = *."course name (max. 30 chars)" 

DFN> [Start with 40 columns and concatenate to avoid EOL 
DFN> STAR40 = "****************************************" 

DFN> STAR80 = STAR40|STAR40 

DFN> [Create the diplomas, ordered by name 

DFN> REPORT STUDENTS SORTED BY STUDENT_NAME ON DIPLOMA.RPT 

DFN> SET NO DATE 

DFN> SET NO NUMBER 

DFN> [Print cover page 

DFN> AT TOP OF REPORT PRINT SKIP 28, STAR80 (-), SKIP, COL 20, 

DFN> "Diplomas for"|||COURSE_NAME (-), SKIP, STAR80 (-) 

DFN> [Print each diploma on a separate page 

DFN> AT TOP OF STUDENT_NAME PRINT SKIP 2, STAR80 (-), 

DFN> SKIP 5, COL 12, 

DFN> "Martin Marietta Energy Systems - Computing Education Group", 
DFN> SKIP 3, COL 30,"Proudly Presents This", 

DFN> SKIP 5, COL 27,"CERTIFICATE OF ACHIEVEMENT", 

DFN> SKIP 2, COL 39,"to", 

DFN> SKIP 3, COL 33,FIRST_NAME|||LAST_NAME (-), 

DFN> SKIP 5, COL 10,"For Successfully Completing a"|||CLASS_LENGTH|| 
DFN> "-day Course of Instruction in" (-), 

DFN> SKIP 3, COL 23, "***"|||COURSE_NAME|||"***" (-), 

DFN> SKIP 5, COL 25, "this", SPACE 1, FN$DAY(END_DATE) (-) USING Z9, 
DFN> SPACE 0, DAY_FORMAT (-), SPACE 1, "day of", SPACE 1, 

DFN> END_DATE (-) USING M(9), SPACE 1, 

DFN> END_DATE (-) USING Y(4), 

DFN> SKIP 8, COL 5, " ", 

DFN> SKIP 1, COL 15, INSTRUCTOR (-), 

DFN> SKIP 5, COL 1, STAR80 (-) 

DFN> AT BOTTOM OF STUDENTNAME PRINT NEW_PAGE 
DFN> END_REPORT 
DFN> END-PROCEDURE 

The above procedure is run as needed to create course diplomas, as indicated below, 
DTR> :diploma 

Enter date class ended: 24-Sep-84 
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Enter number of class days: 4 

Enter instructor (max. 30 characters): Lynn Duncan 

Enter course name ^max. 30 characters): End-User Introduction to DTR 

The resulting reporl starts with a new page containing: 


******************************************************************************** 

Diplomas for End-User Introduction to DTR 
********^^********************************************************************** 


And then a single page is printed to construct the diploma for each student, 
lile the example below. 

******************************************************************************** 


Martin Marietta Energy Systems - Computing Education Group 
Proudly Presents This 

CERTIFICATE OF ACHIEVEMENT 
to 

A1 Carpenter 

For Successfully Completing a 4-day Course of Instruction in 
*** End-User Introduction to DTR *** 

this 24th day of September 1984 


Lynn Duncan 


******************************************************************************** 
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6.2 Formatting for the Terminal 

The Report Writer allows you to set the page length for either a standard printer page or for a terminal 
display. VMS also allows a user to stop terminal scrolling to view data on the screen. BUT have you ever 
had a report scroll off the screen before you finished reading it? There is a way in DTR to hold each page 
of the report on the screen until you’re finished with it. This can be done with a combination of SET 
LINES-PAOE and a prompting expression, as in the example below. 

DTR> SHOW SCREEN-YACHTS 
DELETE SCREEN_YACHTS; 

DEFINE PROCEDURE SCREEN_YACHTS 
READY YACHTS 
REPORT YACHTS ON TT: 

SET REPORT_NAME = "Report of All Yachts"/"One Full Screen at a Time" 

SET LINES_PAGE = 24 
PRINT BOAT 

AT BOTTOM OF PAGE PRINT *."any character to continue" USING X 

END_REPORT 

END-PROCEDURE 

DTR> :SCREEN-YACHTS 

Running the procedure results in the printing of one screen full of information and a prompt for the user 
to control progression throughout the report. 

Report of All Yachts 
One Full Screen at a Time 


MANUFACTURER 

MODEL 

RIG 

LENGTH 

OVER 

ALL 

WEIGHT 

BEAM 

PRICE 

ALBERG 

37 MK II 

KETCH 

37 

20,000 

12 

$36,951 

ALBIN 

79 

SLOOP 

26 

4,200 

10 

$17,900 

ALBIN 

BALLAD 

SLOOP 

30 

7,276 

10 

$27,500 

ALBIN 

VEGA 

SLOOP 

27 

5,070 

08 

$18,600 

AMERICAN 

26 

SLOOP 

26 

4,000 

08 

$9,895 

AMERICAN 

26-MS 

MS 

26 

5,500 

08 

$18,895 

BAYFIELD 

30/32 

SLOOP 

32 

9,500 

10 

$32,875 

BLOCK I. 

40 

SLOOP 

39 

18,500 

12 


BOMBAY 

CLIPPER 

SLOOP 

31 

9,400 

11 

$23,950 

BUCCANEER 

270 

SLOOP 

27 

5,000 

08 


BUCCANEER 

320 

SLOOP 

32 

12,500 

10 


C&C 

CORVETTE 

SLOOP 

31 

8,650 

09 

$25,000 

CABOT 

36 

SLOOP 

36 

15,000 

12 


CAL 

2-27 

SLOOP 

27 

6,700 

09 


CAL 

2-34 

SLOOP 

33 

9,500 

10 


Enter any character to < 

continue:X 






7.0 Summary 

7.1 Putting It All Together - An Example 

A lot of different techniques and methods have been covered. As a summary, one final example will use 
several of them in a single report. Also, a few miscellaneous goodies are included. 

The PERSONNEL record definition and department table are included below for reference. 

DTR> SHOW PERSONNEL-REC 
DELETE PERSONNEL REC; 


17-Sep-1984 
Page 1 
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DEFINE RECORD PERSONNEL REC USING 


01 PERSON. 


05 

ID 

PIC IS 9(5). 

05 

EMPLOYEE_STATUS 

PIC IS X(11) 



QUERY NAME IS STATUS 

QUERY HEADER IS "STATUS" 
VALID IF STATUS EQ "TRAINEE 

05 

EMPLOYEE NAME 

QUERY NAME IS NAME. 


10 FIRST_NAME 

PIC IS X(10) 



QUERY NAME IS F NAME. 


10 LAST_NAME 

PIC IS X(10) 



QUERY NAME IS L NAME. 

05 

DEPT 

PIC IS XXX. 

05 

START_DATE 

USAGE IS DATE 



DEFAULT VALUE IS "TODAY". 

05 

SALARY 

PIC IS 9(5) 

EDIT STRING IS $$$,$$$. 

05 

SUP_ID 

PIC IS 9(5) 



MISSING VALUE IS 0. 


"EXPERIENCED". 


DTR> SHOW DEPT-TABLE 
DELETE DEPT-TABLE; 
DEFINE TABLE DEPT-TABLE 
C82 : COMPTROLLER 

D98 : MARKETING 

E46 : ACCOUNTING 

FI1 : FINANCE 

G20 : COMPUTING 

T32 : TRAVEL 

TOP : CORPORATE 

END-TABLE 


The procedure below creates a report showing the years of service and amount of vacation for each 
employee in each department. It uses variables and a CHOICE value expression, references information in 
a table, allows two levels of control breaks, and includes specialized formatting. 

DTR> SHOW COMP-SER-RPT 
DELETE COMP_SER_RPT; 

DEFINE PROCEDURE COMP_SER_RPT 

ICompute number of years completed; FN$FLOOR gives 
!integer portion only, drops decimal portion 
DECLARE COMPANY_SERVICE_YEARS COMPUTED BY 

FN$FLOOR(("today" - START_DATE)/365.25) EDIT_STRING IS ZZ9. 

DECLARE WEEKS_OF_VACATION COMPUTED BY 
CHOICE 

COMPANY_SERVICE_YEARS GE 20 THEN 5 

COMPANY_SERVICE_YEARS < 20 AND COMPANY_SERVICE_YEARS GE 15 THEN 4 

COMPANY_SERVICE_YEARS < 15 AND COMPANY_SERVICE_YEARS GE 10 THEN 3 

COMPANY_SERVICE_YEARS < 10 AND COMPANY_SERVICE_YEARS GE 5 THEN 2 

COMPANY_SERVICE_YEARS < 5 AND COMPANY_SERVICE_YEARS GE 1 THEN 1 
ELSE 0 
END_CHOICE. 

IStore in file and display on terminal with one pass 
ON CSR.RPT 

REPORT PERSONNEL SORTED BY DEPT, START_DATE ON TT: 

SET COLUMNS PAGE = 70 
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SET REPORT_NAME = ’’Accrued Vacation Report ff / ff By Department” 

!Get department name from table; automatically center by 
!preceding with SKIP 

AT TOP OF DEPT PRINT SKIP, (DEPT VIA DEPT_TABLE) | | |’’Department” (-) 

!0K to break on computed-by variable if based on field in sort key 
AT TOP OF WEEKS_OF_VACATION PRINT COL 5, 

’’Employees wi th” | | | WEEKS_OF_VACATION | | | ”week(s) of vacation:” (-) 

PRINT COL 5, NAME, START JDATE,C0MPANY_SERVICE_YEARS (”Years”/”Service”) 

AT BOTTOM OF WEEKS J)F_VACATION PRINT SKIP 

END__REPORT 

END-PROCEDURE 


The procedure results in a report like the one below. 


Accrued Vacation Report 19~Sep-84 

By Department Page 1 


FIRST 


LAST 

START 

Years 

NAME 


NAME 

DATE 

Service 



COMPTROLLER Department 


Employees 

wi th 

3 week(s) of 

vacation: 


ANTHONY 


IACOBONE 

2-Jan-1973 

11 

Employees 

wi th 

2 week(s) of 

vacation: 


BRUNO 


DONCHIKOV 

9-Aug-1978 

6 

RANDY 


PODERESIAN 

24-May-1979 

5 

DAN 


ROBERTS 

7-Jul-1979 

5 

Employees 

wi th 

1 week(s) of 

vacation: 


JEFF 


TASHKENT 

4-Apr~1981 

3 



MARKETING Department 


Employees 

wi th 

2 week(s) of 

vacation: 


MARY 


NALEVO 

3-Jan-1976 

8 

DEE 


TERRICK 

2-May-1977 

7 

Employees 

wi th 

1 week(s) of 

vacation: 


CASS 


TERRY 

2-Jan-1980 

4 

BART 


HAMMER 

4-Aug-1981 

3 



ACCOUNTING Department 


Employees 

wi th 

2 week(s) of 

vacation: 


GAIL 


CASSIDY 

2-May-1978 

6 

Employees 

wi th 

1 week(s) of 

vacation: 


JOANNE 


FREIBURG 

20-Feb-1980 

4 


7.2 Closing Remarks 

The Report Writer is made up of just a few simple commands but the options and variations that can be 
produced are almost limitless. The Report Writer defaults make it easy to get started; the power and 
flexibility of DATATRIEVE make it possible to do almost anything you can imagine. 

When developing a new report, there is always a certain amount of trial and error. The developer must put 
time, thought and effort into formatting the report to get the desired product. It pays to try new things: Be 

creative. 

The examples included have been simplified for the sake of discussion but still demonstrate some of the 
more advanced or unusual applications of Report Writer. These examples can be easily changed, expanded 
upon, or adapted to fit your applications. 
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The Wombat Wizard 

Philip A. Naecker, Consulting Software Engineer, Altadena, CA 


Exploring Rdb System Relations 

One of the requirements of correctly applied relational technology is that a relational database is com¬ 
pletely self-describing. That is, the database must itself be described using the same data structures used 
to describe the user data in the database. The system relations contain information that describes all the 
relations in the database, including themselves. In Rdb, there is a relation that describes the fields in the 
database, another for all the indexes, and so forth. These relations are collectively called the system 
relations. In database parlance, one says that the system relations contain the database metadata. 

For example, VAX Rdb/VMS uses a relation (a domain in DTR terminology) called RDB$RELATIONS to 
store information about the relations themselves. Rdb writes this relation into the CDD and we can look at 
the relation definition in Datatrieve by READYing that database in a special way. In the following 
Datatrieve session, we will READY the system relations and examine the values of some of the fields. 

DTR> show databases 
Databases: 

SECURITIESJ)ATABASE 

DTR> ready securities^database using rdb$relations 
DTR> show ready 
Ready sources: 

RDB$RELATIONS: Relation, Rdb, snapshot read, consistency 
<_CDD$T0P.USERS.PAN.SECURITIES_DATABASE> 

No loaded tables. 

DTR> show fields 
RDB$RELATIONS 
RDB$RELATIONS 

RDB$RELATION_NAME<Character string, indexed key> 

RDB$RELATION~ID <Number, indexed key> 

RDB$STORAGE_ID <Number> 

RDB$SYSTEMJFLAG <Number> 

RDB$DBKEY_LENGTH <Number> 

RDB$MAX__VERSION <Number> 

RDB$CARDINALITY <Number> 

RDB$FLAGS<Number> 

RDB$VIEWJBLR <Segmented string> 

RDB$DESCRIPTION Segmented string> 

RDB$VIEW_SOURCE <Segmented string> 

RDB$ACCESS_CONTROL <Segmented string> 

No global variables are declared. 
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DTR> print rdb$relation name of rdb$relations 


RDB$RELATION 

NAME 

RDB$RELATIONS 

RDB$FIELD_VERSIONS 

RDB$INDICES 

RDB$INDEX_SEGMENTS 

RDB$FIELDS 

RDB$RELATION_FIELDS 

RDB$DATABASE 

RDB$CONSTRAINTS 

RDB$CONSTRAINT_RELATIONS 

RDB$VIEW_RELATIONS 

COMPANIES 

COMPANY_TYPES 

CURRENCIES 


These are Rdb's 

| system relations 


These are user 
relations... 


DTR> rollback ! Either ROLLBACK or COMMIT is required 

! before we can do another READY 
! from the same database. 

DTR> ready securities_database using rdb$fields 
DTR> show ready 
Ready sources: 

RDB$FIELDS: Relation, Rdb, snapshot read, consistency 
<_CDD$T0P.USERS.PAN.SECURITIES_DATABASE> 

RDB$RELATIONS: Relation, Rdb, snapshot read, consistency 

<_CDD$TOP.USERS.PAN.SECURITIES_DATABASE> 

No loaded tables. 


DTR> show fields for rdb$fields 
RDBSFIELDS 
RDB$FIELDS 

RDB$FIELD_NAME <Character string, 
RDB$FIELD_TYPE <Number> 
RDB$FIELD_LENGTH <Number> 
RDB$FIELD_SCALE <Number> 
RDB$SYSTEM_FLAG <Number> 
RDB$EDIT_STRING <Character string> 
RDB$FIELD_SUB_TYPE <Number> 

RDB$QUERY_NAME Character string> 
RDB$SEGMENT_LENGTH <Number> 

RDB$VALIDATION_BLR <Segmented 

RDB$COMPUTED_BLR <Segmented string> 
RDB$MISSING_VALUE<Segmented string> 
RDB$DESCRIPTION <Segmented string> 
RDB$VALIDATION_SOURCE <Segmented 
RDB$COMPUTED_SOURCE Segmented 

RDB$QUERY_HEADER <Segmented string> 
RDB$DEFAULT_VALUE<Segmented string> 


indexed key> 


string> 


string> 

string> 


DTR> print rdb$field name, rdb$field length of first 5 rdb$fields 



RDB$FIELD 

NAME 


RDB$FIELD 

LENGTH 


RDB$RELATION_NAME 31 
RDB$RELATION_ID 2 
RDB$STORAGE_ID 2 
RDB$SYSTEM_FLAG 2 
RDB$DBKEY_LENGTH 2 


These system relations contain all the information about the database I have defined. The information 
about the fields is stored in RDB$FIELDS. Information about the relations is stored in 
RDB$RELATIONS. Information about which fields are in which relations, and in what order, is found in 

rdb$relation_fields. 

What is the difference between RDBSFIELDS and RDB$RELATION_FIELDS, and why does Rdb need 
both of them? In an Rdb relational database, fields are defined globally. That is, when you define a field, it 
is associated with no particular relation. To associate a field with a relation, you must include it explicitly. 
Here is some RDO definition text: 

DEFINE FIELD EMPLOYEE_NUMBER DATATYPE IS SIGNED LONGWORD 

QUERY_HEADER FOR DTR IS "Empl."/"No." 

QUERY_NAME FOR DTR IS "EMPNO" 

EDITJSTRING IS Z(5). 

DEFINE RELATION SALARY_HISTORY. 

EMPLOYEE_NUMBER. 

REVIEW_DATE. 

SALARY. 

END SALARY_HISTORY RELATION. 

DEFINE RELATION MENTORS. 

MENTOR_EMPNO BASED ON EMPLOYEE_NUMBER. 

STUDENT_EMPNO BASED ON EMPLOYEE_NUMBER. 

LAST_REPORT_DATE. 

END MENTORS RELATION. 

Here we have defined a field (EMPLOYEENUMBER) and have used it in two relations. Each field in the 
relations would have to be defined before the relation is defined, but for simplicity I’ve left some out. Note 
that in the first relation (SALARYJHISTORY) we simply reference the field to include it in the Rdb 
relation. In the second relation (MENTORS) this would not work, because we want to use the same global 
field (EMPLOYEE_NUMBER) for both the mentor and the student. Here we use the BASED ON field 
attribute. This makes the relation fields take on the attributes (field length, query-header, and so forth) of 
the global field. Similarly, if we change the global field the based-on fields will be changed automatically. 

Now we can see the reason for RDBSFIELDS and RDB$RELATTON_FTET DS. RDR$FIELDS contains 
the information about all the global fields in the database - their size, datatype, and so forth. 
RDB$RELATION_FIELDS contains both the field name of the local fields (e.g., MENTOR_EMPNO) as 
well as the name of the global field on which it is based (e.g., EMPLOYEENUMBER,) (This is the type 
of classical data normalization that all Datatrieve users should be applying in their own applications!) 

Since we can READY these relations with Datatrieve, why not do some DTR manipulation of the data? We 
can’t STORE or MODIFY these relations (usually) because those sort of operations require additional 
functions be performed that cannot be performed using DTR. But we can REPORT on the relations and 
get useful information that way. Consider the following three reports. 
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The first report describes the fields in each relation. We use an RSE that excludes the system relations 
(which all start with RDB$) we sort the records by relation name and field name so we can do some AT 
BOTTOM of processing. We also use a virtual field called SOURCE_FIELD that prints the name of a 
source field (RDB$FIELD_SOURCE) only when the source field is different than the field itself. 

DELETE FIELDS_BY_RELATION_REPORT; 

REDEFINE PROCEDURE FIELDS_BY JRELATION_REPORT 

! 

READY SECURITIES_DATABASE USING RDB$RELATION_FIELDS READ 

i 

DECLARE SOURCE_FIELD COMPUTED BY CHOICE 

RDB$FIELD_SOURCE EQ RDB$FIELD_NAME THEN "" 

ELSE RDB$FIELD_SOURCE 
END_CHOICE. 

! 

ON FIELDS_BY_RELATION.LIS 
ON TT: 

REPORT RDB$RELATION_FIELDS WITH RDB$RELATION_NAME NOT CONT "RDB$" SORTED BY 
RDB$RELATION_NAME, RDB$FIELD_NAME 
SET REPORT_NAME = "Fields by Relation" 

AT TOP OF RDB$RELATION_NAME PRINT COL 1, RDB$RELATION_NAME ("Relation") 

PRINT COL 5, RDB$FIELD_NAME ("Field Name"), 

COL 40, SOURCE_FIELD ("Source Field") 

AT BOTTOM OF RDB$RELATION_NAME PRINT SKIP 1 
END_REPORT 

j 

END-PROCEDURE 


Fields by Relation 


15-Mar-1987 
Page 1 


Relation 


Source Field 


COMPANIES 

COMPANY_DESCRIPTION 

COMPANY_NAME 

COMPANY_NUMBER 

COMPANY_TYPE 

C0UNTRY_0F_INC0RP0RATI0N COUNTRY 

FISCAL_YEAR_END 

LATEST_UPDATE 

PARENT_COMPANY COMPANY_NUMBER 

SIC_C0DE 

STATE_0F_INC0RP0RATI0N 

COMPANY_TYPES 

COMPANY_TYPE 

COMPANY_TYPE_DESCRIPTION 
COMPANY TYPE NAME 
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In the next report, we are going to report on which relations use each field. This sort of report is a simple 
way to find out which fields are candidates for foreign keys, because only fields that appear in more than 
one relation are good candidates for keys to be used in a relational join. Note that both 
COMPANY NUMBER and COMPANY_TYPE are thus good candidates for a join key. Note also that 
LATEST UPDATE contains multiple references, but since that is simply the date of last update of the 
relation, there is not a lot of value in doing a join on that field! 


DELETE RELATIONS_BY_FIELD_REPORT; 

REDEFINE PROCEDURE RELATIONS_BY_FIELD_REPORT 

I 

READY SECURITIES_DATABASE USING RDB$RELATION_FIELDS READ 

i 

DECLARE SOURCE_FIELD COMPUTED BY CHOICE 

RDB$FIELD_SOURCE EQ RDB$FIELD_NAME THEN "" 

ELSE RDB$FIELD_SOURCE 
END_CHOICE. 

i 

i 

ON RELATIONSJBY_FIELD.LIS 
ON TT: 

REPORT RDB$RELATION_FIELDS WITH RDB$RELATION_NAME NOT CONT "RDB$" SORTED BY 
RDB$FIELD_NAME, RDB$RELATION_NAME 
SET REPORT_NAME = "Relations by Field" 

AT TOP OF RDB$FIELD_NAME PRINT COL 1, RDB$FIELD_NAME ("Field") 

PRINT COL 5, RDB$RELATION_NAME ("Relation Name") 

AT BOTTOM OF RDB$FIELD_NAME PRINT COL 40, 

COUNT ("Number of"/"Relations"), 

SKIP 1 

END_REPORT 

l 

END-PROCEDURE 


Relations by Field 


15-Mar-1987 
Page 1 


Field 


Number of 
Relations 


C0MPANY_DESCRIPTI0N 

COMPANIES 


1 


COMPANY_NAME 

COMPANIES 


1 


COMPANY_NUMBER 

COMPANIES 

SECURITY_ID_TRANSLATIONS 

2 


COMPANY_TYPE 

COMPANIES 
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COMPANY TYPES 


2 


COMPANY_TYPE_DE SCRIPTION 
COMPANY TYPES 


1 


COMPANY_TYPE_NAME 
COMPANY TYPES 


1 


LATEST_UPDATE 
COMPANIES 
CURRENCIES 
DISTRIBUTIONS 
MARKETS 
PRICE_HISTORY 
SECURITY_ID_TRANSLATIONS 
SECURITY_INFO 

7 


The third and last report is very similar to the second report, except that the field is analyzed based on the 
original source field instead of the field name in the relation. It provides analysis of the use of the global 
fields in the database. Note that this analysis reveals two more relations that contain references to the 
global field COMPANY NUMBER, fields that have local field names which are different from the global 
field name. 

DELETE RELATIONS_BY_SOURCE_REPORT; 

REDEFINE PROCEDURE RELATIONS_BY_SOURCE_REPORT 

I 

READY SECURITIES_DATABASE USING RDB$RELATION_FIELDS READ 

f 

ON RELATIONS_BY_SOURCE.LIS 
ON TT: 

REPORT RDB$RELATION_FIELDS WITH RDB$RELATION_NAME NOT CONT "RDB$" SORTED BY 
RDB$FIELD_SOURCE, RDB$RELATION_NAME 
SET REPORT_NAME = "Relations by Source Field" 

AT TOP OF RDB$FIELD_SOURCE PRINT COL 1, RDB$FIELD_SOURCE ("Source 
Field'V'and Relation") 

PRINT COL 5, RDB$RELATION_NAME, 

COL 40, RDB$FIELD_NAME ("Actual Field") 

AT BOTTOM OF RDB$FIELD_SOURCE PRINT COUNT ("Number of"/"Relations"), 

SKIP 1 
END_REPORT 

t 

END-PROCEDURE 


Relations by Source Field 


15-Mar-1987 
Page 1 


Source Field 


Number of 
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and Relation 


Actual Field 


Relations 


COMPANY_DESCRIPTION 

COMPANIES 


COMPANY DESCRIPTION 


1 


COMPANY_NAME 

COMPANIES 


COMPANY NAME 


1 


COMPANYJMUMBER 
PARENT_COMPANY 
COMPANY_NUMBER 
ISSUER 

4 

COMPANY_TYPE 

COMPANIES COMPANY_TYPE 

COMPANY TYPES COMPANY_TYPE 

2 


COMPANY_NUMBER 

COMPANIES 

COMPANIES 

SECURITY_ID_TRANSLATIONS 
SECURITY INFO 


Obviously, there are many other things that one can do using the Rdb system relations. For example, you 
might write reports on the usage of your indexes (stored in RDB$INDICES and 
RDB$INDEX_SEGMENTS), about views (RDB$VIEW_RELATIONS>, about constraints 
(RDB$CONSTRAINTS and RDB$CONSTRAINT_RELATIONS). 

Keep those cards and letters coming! 
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FROM THE EDITOR... 

You may notice a more consistent typestyle and format in this issue. It is the first OA issue put together 
using the ALL-IN-1 tool ’DECpage’, DECpage produces typeset style output to a laser printer. We will be 
discussing how to submit electronically in future issues. For now, anyone with articles should contact me 
first to discuss methods of submission. 

We have two highlighted technical articles in this issue: Setting VMS Passwords for Captive Accounts, and 
Starting the All-In-1 to Message Router Batch Jobs Automatically during System Startup. I am sure you 
will find these ’how to’ type articles useful at your own facilities. 

We also have our regular Notes column which I have received some very positive comments about. I am 
glad to see that our articles are being used to help solve your questions and problems. Please feel free to 
call or write with comments about articles in the newsletter. 

Regards, 

Therese 


Therese LeBlanc 
OA Newsletter Editor 
275 London Place 
Wheeling, IL 60090 
(312) 459-1784 
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SETTING VMS PASSWORDS FOR CAPTIVE ALL-IN-1 ACCOUNTS 

John Mulhollen, Senior Computer Program Coordinator, TRW, San Bernadino, CA 


We have a large complement of captive ALL-IN-1 users and for security reasons have stripped them of 
DCL and Command privileges and implemented system-generated VMS passwords (GENPWD in 
AUTHORIZE). We had no problems with this procedure for a little over three months — until passwords 
started to expire. Users would be told at login time that their VMS password was about to expire (and it 
finally would), but were never afforded the opportunity to change it! 

The system manager did not appreciate being inundated with requests to change VMS passwords (and turn 
on the accounts of those unfortunate souls who allowed their passwords to expire), so we developed an 
ALL-IN-1 command file (CPW.COM) to allow the captive ALL-IN-1 user to change his or her own password 
without the intervention of the system manager. 

Copy CPW.COM into 0A$LIB2: (or whatever directory you use for site specific ALL-IN-1 enhancements) 
and modify the menu form you want to be able to call CPW from (we chose MAIN2,, but you could use 
DEFAULT to allow CPW to be called from any menu). In our specific case, we modified the named data of 
MAIN2 as follows: 

CPW 

Command 0A$LIB2:CPW/CLEAR 

When called, CPW allows the non-DCL privileged user to utilize the VMS SET PASSWORD command 
from within ALL-IN-1. A successful change of password results in the message "VMS password changed", 
while the message "VMS password not changed" will be displayed if the SET PASSWORD command 
should fail for any reason. 

Here is the command file we used: 

$! CPW.COM — command file to change VMS password from ALL-IN-1 
$! 6 Aug 1986 J. Mulhollen 

$! 

$ on error then goto PW_NOT_CHANGED 

$ write oamailbox "OA SHOWFORM BLANK" 

$ @dclmailbox 

$ write sys$output " " 

$ write sys$output "VMS Password Change: " 

$ write sys$output " " 

$ write sys$output " " 

$ assign /nolog sys$command sys$input 

$ SET PASSWORD 

$! if this DCL command errors out, control is passed to PW NOT CHANGED 
$! if the command is successful, control continues here... 

$ write oamailbox "OA CLEAR" 

$ write oamailbox "OA DISPLAY VMS Password has been changed" 

$ @dclmailbox 

$ exit 

$! 

$ P W_N OT_C H ANGE D: 

$! comes here if SET PASSWORD errors out 

$ write oamailbox "OA DISPLAY VMS Password not changed" 

$ ©dclmailbox 

$ exit 
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Starting the AII-ln-1 to Message Router Batch Jobs Automatically 
during System Startup 

Bart Z. Lederman, ITT World Communication, New York, NY 10004-2464 


All-In-1 V2.1 uses the Message Router and Message Router VMS Mail Gateway to exchange electronic 
mail between All-In-1 users and VMS Mail users on the same system (node), or on different systems (nodes 
in a network). In order for this to work, however, there must be two batch jobs scheduled to run at regular 
intervals which exchange mail between the Message Router and All-In-1. For example, with all of the 
Message Router products installed and running, a SHOW QUEUE/ALL command should look something 
like this (you will see two sets of queues here as I have a two node cluster): 

$ show queue/all 

Generic batch queue MB$BATCH 


Jobname 

Username 

Entry 

Status 

MB$MR 

MRMANAGER 

1765 

Holding until 13-MAR-1987 09:17 

MB$MG 

MRGATE 

1769 

Holding until 13-MAR-1987 09:22 

MB$NET 

MRMANAGER 

1770 

Holding until 13-MAR-1987 09:27 


Batch queue MB$BATCHSYS30, on SYS30:: 
Batch queue MB$BATCHSYS31, on SYS31:: 
Generic batch queue SYS$BATCH 
Batch queue SYS30BATCH, on SYS30:: 
Batch queue SYS31BATCH, on SYS31:: 


Jobname 

Username 

Entry 

Status 

MRTOVMS 

MRGATE 

1777 

Holding until 13-MAR-1987 09:20 

OAMTISEND 

ALLIN 1 

1782 

Holding until 13-MAR-1987 09:23 

OAMTIMAI1 

ALLIN 1 

1784 

Holding until 13-MAR-1987 09:28 

MRTIDY 

MRMANAGER 

1717 

Holding until 14-MAR-1987 03:00 


The two queues which exchange mail between All-In-1 and the Message Router are OAMTISEND and 
OAMTIMAIL. 

The other jobs (MRTOVMS, MRTIDY, etc.) are automatically started when your system is booted by the 
Message Router or Message Manager startup command files (if you have followed the installation instruc¬ 
tions and added the command files to your SYSTARTUP.COM file), but the two All-In-1 jobs are NOT 
started: You have to manually start them using All-In-1. I find this inconvenient: I would much rather have 
everything start automatically when I boot my system. To solve this problem, I have developed a batch 
procedure which can be invoked during system startup to insure that everything is running. 

To invoke this command procedure, you must submit a batch job AFTER the queue manager has been 
started, and AFTER All-In-1 has been started. Normally, in your SYS$MANAGER:SYSTARTUP.COM 
file you will have the command to start the queue manager before you invoke the All-In-1 startup command 
file: Therefore, you can make a simple change to SYS$MANAGER:A1 V2START.COM shown here be¬ 
tween the rows of exclamation points: 


QA-3 



$ ! Run ALLIN 1 to install the forms and TXL libraries 

$ set noon 

$ ALLIN 1/NOINIT 

oa$fbtremovelib oa$lib:memres 

oa$fbtremovelib oa$lib:oaform 

oa$txlremove 

oa$fbtinstalllib oa$lib:memres 
oa$fbtinstalllib oa$lib:oaform 
oa$txlinstalJ 
$! 

$ !!!!!!!!!!!!!!!!!!!!!! f, ! ff? ! n !!!! f !! ! ! t 
$! 

$! Make certain the mail queues have started. 

$! Must be a batch job as it has LIN1 account. 

$! 

$! B. Z. Lederman 

$! 

$ submit/user=ALLIN 1 sys$manager:almailstart.bat 

$! 

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

$! 

$ set on 

$ ! 

The batch file A1MAILSTART.BAT looks like this: 

$! This should startup the All-In-1 to Message Router 
$! batch queues. 

$! 

$! B. Z. Lederman 12-Mar-1987 


$! 

$ ALLINl/USER = MANAGER/NOINIT 
COMMAND EMCONTROL SS 
COMMAND EMCONTROL SF 
$! 

$ PURGE A1MAILSTART.LOG 

$! 

$ EXIT 

The reason for making this a batch job is because you usually have to be in the (All-In-1) MANAGER 
account, or another privileged account, to invoke commands like starting and stopping mail. The default 
profiles for All-In-1 require that you be in the (VMS) ALLIN1 account in order to use the (All-In-1) 
MANAGER account, so by submitting the batch job with the /USER=ALLIN1 qualifier, I insure that the 
job will be done in the proper account. Also, my system startup is a little faster because I don’t have to wait 
for All-In-1 to do the work of starting the queues. 

It was stated earlier that the All-In-1 batch jobs don’t start automatically. In practice, this depends upon 
what state the batch queues are in when the system shuts down and re-boots. It is possible for a batch job 
which was scheduled before the system shuts down to still be scheduled when the system re-boots: But it 
is also possible for batch jobs to be "lost", especially if you have to re-initialize the queue manager. This 
procedure is intended to insure that all of the necessary batch jobs are started when the system is 
re-booted regardless of the state of the queue manager. 
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Notes on Notes 

— Discussions on VAX Notes - Volume 1, Number 6 

by Mark Hyde and C J Trayser, VAX Notes Support Specialists, Digital Equipment Corporation 


VAX Notes has been announced for almost a year, has been shipping for over nine months and this begins 
our sixth month of this article. Hopefully you should all have had time to get Notes installed and running 
and to have become familiar with its features and functions. By now you have probably had the opportunity 
to use a VAX Notes’ conference for a real business situation. Somebody mentions that the information that 
might be discussed is pretty sensitive and wants to know how secure the Notes environment is. VAX 
Notes, much like VMS, can be made more or less secure at the discretion of the system manager. Our goal 
this month is to clarify some of the issues surrounding conference security. 

Some of the questions that usually come up are: 

• Do I want people (anyone) to be able to create a conference in the NOTES$LIBRARY 
directory? 

• Do I need to secure the file(s) from any individual, group or class of user? 

• Should I have conferences restricted based on a membership list? 

• Should people on only one certain node have access? 

• Can I restrict certain people from accessing specific conferences? 

• Should the file be read only for some people and read/write for others? 

• Should certain users have certain privileges in a conference? 

As you can see, the choices can be both difficult and confusing. So 

to properly address solutions to address these questions we must first understand about the different ways 
VAX Notes accesses the conference files. 

File Access 

Notes allows access to conferences in two different ways, by either a direct RMS open of the conference file 
or by the use of the Notes server (a detached DECnet job, much like a generic NETSERVER). The 
’standard’ file open, that everyone should be familiar with, is what we refer to as ’direct’ access. This is 
where the Notes program that the user runs (usually called the ’client’ software) will issue the file open and 
does all the reading and writing to the conference file. When using this mode, each person accessing the 
conference has the file open and is reading and writing at the same time. The following diagram illustrates 
direct access concept: 


Direct access is only allowed to conferences which reside on the same machine as the user, and. like any 
RMS access to a file, is subject to UIC based protection, user privileges, as well as ACL’s. Dealing with 
direct access means having to consider the many variations of those items that might occur in the typical 
VMS system. 

Direct access is accomplished by NOT using the DECnet node name as a part of the conference file 
specification when adding the entry to your notebook: 

Notes > ADD ENTRY TRUCK ! For direct access 

Notes > ADD ENTRY MYNODE::TRUCK ! For server access 
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If Notes finds the node name as part of the file specification, it will invoke "server" access to the file. The 
server is a job running on the remote system that is able to accept connects and process requests from the 
users for the conference file. The server can accept connects an process requests from multiple users at the 
same time to the same or different conference files. The following diagram illustrates in a simple manner 
the concept of using the Notes server: 



The server is a detached DECnet job that runs from an account named NOTES$SERVER. This was 
created during the installation of VAX Notes. If you prefer server access to all conferences, you will then 
have all access to the conferences taking place via a single UIC, which greatly simplifies the security effort. 
Requiring the use of the server for all accesses, both local and remote, is probably the best and easiest 
method for controlling conference security. 

Server access is always used for accessing conferences on a remote node. It can also be used to access 
conferences on the local VAX. Of course, using the server means that your system must be running 
DECnet. 

File Protection 

As installed, NOTES$LIBRARY.DIR is owned by SYSTEM and has an ACL that disallows any 
NETWORK access to the directory and, specifically allows access for NOTES$SERVER. 

NOTES$LIBRARY.DIR;l [1,4] (RWE,RWE,RE,RE) 

(IDENTIFIER=[NOTES$SERVER],ACCESS = READ-f EXECUT) 
(IDENTIFIER=NETWORK,ACCESS = NONE) 
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This protects against anyone outside your node getting to the actual notes files themselves, and prevents 
non-privileged users from creating conferences directly in NOTES$LIBRARY directory. However, it does 
not control privileged users. 

Notes offers a command procedure that you will find in SYS$MANAGER: called 
NOTES$MOVE_CONFERENCE.COM. This will take care of creating a relatively secure conference envi¬ 
ronment, but again, does not fully address privileged users. To use this procedure: 

• First create the conference file in one of your own directories (i.e. SYS$LOGIN). 

• Have a privileged user move the conference by executing the 

SYS$MANAGER:NOTES$MOVE CONFERENCE.COM file. 

This command procedure queries you for the location and name of the conference file, the username of the 
moderator, and whether or not you want to require server access. It then: 

• moves the conference file to NOTES$LIBRARY 

• changes its ownership to SYSTEM if server only access 

• sets file protection and applies an ACL based on whether or not you require server access. 

If you require server access, the file itself is protected from all access except by the server, the moderator, 
and privileged users, and looks like this: 

TRUCK. NOTE: 1 [SYSTEM] (RWE,RWE„) 

(IDENTIFIER —[NOTES$SERVER], ACCESS = READ T WRITE-h EXECUTE) 
(IDENTIFIER=INTERACTIVE,ACCESS = NONE) 

(IDENTIFIER—BATCH, ACCESS = NONE) 

(IDENTIFIER^ NETWORK, ACCESS —NONE) 

(IDENTIFIER=[HYDE],ACCESS = READ T WRITE + EXECUTE + CONTROL) 

If you do not require server access, the file itself is still protected from network access, but is not protected 
from local users. The conference may be opened via the server or direct access and looks like this: 

TRUCK. NOTE; 1 [HYDE] (RWE,RWE,RWE,RWE) 

(IDENTIFIER=[NOTES$SERVER],ACCESS = READ + WRITE + EXECUTE) 

(IDENTIFIER^ [HYDE],ACCESS = READ + WRITE + EXECUTE + CONTROL) 
(IDENTIFIER=[DECNET],ACCESS“NONE) 

(IDENTIFIER=NETWORK,ACCESS = NONE) 

In some cases, such as on MicroVMS, users may not have or may not choose to use the ACL protection 
mechanism. Here is an alternative protection scheme that does not make use of ACL’s. 

• Set the ownership of the NOTESSLIBRARY.DIR file and all of the conferences in 
NOTES$LIBRARY to be owned by the [NOTES$SERVER] UIC. 

• Set the protection mask on the NOTESSLIBRARY.DIR file to (S:RWE,0:RE,G:RE,W:RE), 
which, if you noticed, does NOT allow OWNER to WRITE! 

• Set the protection mask on all of the conference files to be (S:RWE,0:RWE,G,W). 

• Add a (large) diskquota entry on the NOTESSLIBRARY disk for the [NOTESSSERVER] 
UIC. 

This scheme does the following: 

• Allows the system manager to track disk usage easier since all Notes related files now have 
a Notes UIC instead of a System UIC. 

• Allows access to the Conferences to ONLY the SERVER and privileged users. 

• Prevents users from creating conferences in the NOTES$LIBRARY directory be not allow¬ 

ing Owner to Write (0:W). 
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Certain users can be allowed to only read while other users are allowed to write or read for local 
conferences. This is not a built-in feature, but is easily achieved by: 

• Creating a Rights Identifier in Authorize for ’Writers’ via Authorize. 

• Granting that identifier to ’Writers’ via Authorize. 

• Adding an ACL with the Rights Identifier (just created) to the conference gives the holders of that 
identifier file access as defined by the ACL. 

• Set the file protection to (S:RE,0:RE,G:RE,W:RE) and require the ’writers’ to use direct access (i.e. 
NOT through the server). 

All of this will allow those people with the rights identifier to be able to write to the conference and 
restricts others to read-only mode. 

Another idea is to create separate library directories, perhaps on different disks and to define the 
NOTES$LIBRARY logical at the group level. This requires that the conferences be accessed directly, not 
using the server access, since it has its own UIC. This scheme allows different groups to only access 
conferences in their ’group defined’ Notes library. This idea can be expanded to include system search-lists 
for the Notes$library logical. 

Membership Protection 

Thus far we have only talked about physical access to the conference files themselves. Earlier in our 
’questions’ we alluded to the fact that you could give members privileges. The two privileges that are 
available with the current version of Notes are ’keyword^create’ and ’moderator’. The keyword create 
allows you to define a keyword that other noters may attribute to different entries in the conference. Any 
user may associate an existing keyword with a note via the ADD command, but only users with the create 
privilege can cause a new keyword to exist. 

The other privilege is the Moderator privilege. This privilege, when assigned to a member of the 
conference, allows that user to do the following: 

• Add and/or modify members and their privileges. This includes making other members a 
moderator. 

• Set any note to ’hidden’. This sets a note so that ONLY the author and moderators can see 
the text. The banner (which includes title, author, date, etc.) is still visible. 

• Modify the title of any note. 

• Write to a conference or a note that has been set to NOWRITE. 

• Delete ANY topic or reply. 

Using this information and your own needs, you should be able to construct a protection scheme to meet 
your conference security needs. The ability to offer more of this kind of control from within the product 
itself is high on the wishlist for a future version. 

Happy noting :-) 
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(THE (LINKED LIST)) 

The Newsletter of the DECUS Artificial intelligence 
Special Interest Group 

"... It's The Real Thing" 

Vol. 3 No. 4 May 1987 

From The Editor: 

This issue of (THE (LINKED LIST)) marks the beginning of the 
newsletter's third year of publication. Although the news¬ 
letter has a somewhat sporadic publication record, it's hard to 
say that the growth of the DECUS Artificial Intelligence 
Special Interest Group has been anything but consistent. Given 
Digital's stance on applied artificial intelligence as a 
corporate asset, the AISIG's continued growth is a virtual 
certainty. 

During the past two years, AI has become a commercially viable 
tool instead of a journalistic buzzword. LISP machine vendors 
whose hardware provided the first AI application development 
and delivery platforms have been joined by manufacturers of 
conventional data processing equipment. During the brief 
period that (THE (LINKED LIST)) has tracked Digital's signifi¬ 
cant contributions to the field of AI, even IBM, no friend of 
unproven technology, has decided that the time is right to 
begin delivering AI solutions to its users. 

Digital Equipment Corporation is, quite understandably, tight- 
lipped about future product directions and corporate 
strategies. While I'm not privy to the details of Digital's 
game plan, I did happen to notice that Ken Olsen used the 
phrases "networking" and "artificial intelligence" in the same 
sentence when he addressed the attendees at Digital's annual 
stockholder's meeting . . . 

(THE (LINKED LIST)) is the only medium through which the AISIG 
can manifest itself to the thousands of DECUS members who can¬ 
not attend symposia. A newsletter cannot, however, do justice 
to the DECUS volunteers whose efforts have transformed the 
AISIG from a nascent concept into a dynamic special interest 
group. Page count limitations preclude me from listing each 
individual contributor, but the efforts of SIG Chair Cheryl 
Jalbert, Assistant Chair Don Rosenthal, Digital Counterpart Art 
Beane, Symposium Coordinator Pam Vavra and SIG Guru Dr. David 
Slater warrant special recognition. And, given my position as 
SIG newsletter editor, I'd be remiss if I didn't convey my 
appreciation to my readers and contributors. Thanks much!!! 

Terry C. Shannon 

As usual, (THE (LINKED LIST)) welcomes your articles, book 
reviews, comments and suggestion. For further information, 
give me a call at (617) 375-4321. 


AI KNOW HOW 

Edited by D. Frydenlund 

"AI Know How" is a brand new column in this newsletter. Its 
purpose is to allow a forum for the free exchange of 
information about the world of Artificial Intelligence and its 
contributions. This column will draw on the collective wisdom 
of the AISIG's members and steering committee, contacts at 
Digital and additional sources to answer virtually any 
question about AI. 

"AI Know How" grew out of discussions at various symposia which 
fundamentally addressed the issue of "Where can I go or who can I 
talk to to get additional information about AI?" 

This column is here to provide you an opportunity to "talk to the 
wizards" and at least get pointed in the right direction. Of 
course, the DECUS commercialism policy and other standards 
will apply to the questions and answers published here. 

To get more "AI Know How", address your questions to me and I 
will help you find an answer. 


David Frydenlund 
10839 Broadwater Dr. 
Fairfax, VA. 22032 


Question 1: 

My Department has been using a Public Domain OPS for doing 
quick feasibility studies involving various pattern matching 
problems. We are considering the purchase of a fully 
supported OPS (or equivalent INEXPENSIVE rule-based system), 
to run on our VAX running VMS, and need some guidance. 

I have used OPS5 before, and like it, but don't really know 
how it compares to OPS83, etc. I am less concerned with 
performance than functionality, in general. I'd like to see a 
comparison table listing important features and limitations of 
various production systems, from a guru rather than from a 
vendor or well-intentioned novice researcher. Often times, 
I'll be told that a particular feature does not exist in OPS5, 
for example, but later learn from my OPS5 guru friend that, 
while it is not immediately evident, the feature is very 
easily constructed. Thanks for any 'AI Know-How' you can 
provide. 

Pam Vavra 
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Report on IEEE Database and Knowledge Base Conference 
By Becky Selke 

The Dallas Chapter of the IEEE Computer Society sponsored a 
conference here at the University of Texas at Dallas, entitled 
New Directions in Database and Knowledge Management systems. 

In addition to speakers from several local universities, 
companies such as Texas Instruments contributed as well. The 
talks addressed topics in both relational database and 
knowledge based systems areas. Several talks addressed 
methods of combining knowledge based systems with conventional 
DBMS's. Applications were discussed in VLSI design, gate 
scheduling for airports, and telecommunications. 

Issues such as the special problems of spatial and temporal 
databases and knowledge bases were also addressed. It was 
apparent from the conference that there is no universal right 
answer to any of the questions posed. There is however, an 
impressive diversity of solutions being proposed. 

It is encouraging for there to be cooperation between the 
database and the AI people. Several papers examined the 
transfer of technology between these two fields to solve 
problems. It must be recognized that solutions to AI problems 
need not be discovered strictly in AI research. 

The conference was the first sponsored by the local chapter. 
There were over 40 papers scheduled for presentation. It was 
an impressive first attempt for a conference from the group. 

We are hopeful that other conferences such as this will be 
offered in the area. 


IEEE Conference on Artificial Intelligence Applications Report 
By Jim Sims 

The IEEE Conference on applications of Artificial Intelligence 
was held at the Hyatt Orlando Feb 23-27, 1987. Feb 23rd and 
24th consisted of two half-day tutorials each day on various 
topics. Each of the three remaining days included a keynote 
address by a well known AI researcher or implementer, followed 
by a morning and afternoon session of user-presented papers. 

I attended the tutorials on Analyzing Expert System Building 
Tools and Managing Knowledge System Development on Feb 23rd 
and the AI & Computer Integrated Manufacturing and AI 
Programming on Parallel Machines tutorials on Feb 24th. The 
tutorials were of average quality except the last which was 
very good. The first two talks were given by consultants and 
were oriented towards a novice level audience. The talk on AI 
and CIM was really a talk about Carnegie Group's attempt to 


solve all the problems of CIM by scheduling things based on 
constraints. This was a typical solution looking for a 
problem. The last talk on AI and Parallel machines was quite 
informative and rapidly escalated from a definition of basic 
terms to a discussion of complex problems and solution 
approaches. The speaker, Joe Brandenburg of Intel, was very 
interesting and obviously enjoyed talking about his work. His 
style was very energetic and facilitated user ideas and 
interaction in an organized manner. 

The first keynote address was given by Gary Hendrix of 
Semantec on AI and Natural Language in the Real World. It was 
quite humorous and informative, illustrating many of the 
common pitfalls in the development of an AI product. The major 
lesson to be learned was to do AI because it solves a problem, 
not because it's AI. Other points included not getting 
yourself tied too tightly to venture capitalists, properly 
defining what you are going to build and how (and not swaying 
for money), and the value of proper marketing. 

The Wednesday morning session I attended was for several 
invited talks. Both talks concerned the use of qualitative 
models for knowledge bases and the integration of separate KBs 
into functioning systems, much in the manner that CAD systems 
are currently evolving into CIM systems. The model-based 
reasoning paradigm seems to be emerging as a forerunner of the 
AI reasoning methods. It seems natural since humans reason 
about everything in this manner. 

The afternoon session was on Manufacturing. I attended the 
Knowledge-based Imaging system for NDT and the Object Based 
programming system for parts routing. The first session was 
interesting in that it provided an example of a method for 
determining properties of a system based on knowledge of the 
structure and a test signal. This inversion process is not 
solvable analytically. The second system allows manufacturing 
engineers to route parts based on Group Technology utilizing a 
rule based Expert System. The last talk was on visual based 
inspection of solder joints. This paper discussed statistical 
fits of data, use of an expert system to grade the joints, 
comparison of the statistical, Expert System, and human 
evaluators, and the use of computer generated rules to 
populate the expert system. It was very interesting. 

The keynote address on Thursday was given by John Laird of the 
University of Michigan on Expert Systems in a General 
Cognitive Architecture. This talk was informative in a general 
sense, but not in a concrete, specific manner. 

The first paper session was concerned with Explanation-Based 
Learning systems. The talks centered around the weaknesses of 
EBL systems and methods for overcoming these problems. This is 
an area which appears to need quite a bit of research before 
any major paybacks are realized in general systems 
applicability. 
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The afternoon sessions I attended were on Robotics & 

Perception and Diagnosis Systems. The first paper was about 
terrain acquisition for a mobile robot among polyhedral 
obstacles. The subject was well covered and seemed trivial 
when approached from the proper perspective. The next talk was 
given by David Rolston of Honeywell on a system for diagnosis 
of mainframe peripherals. This talk illustrated some of the 
untenable payoffs of using Expert Systems, including 
consistency of policy application. 

The Honeywell field service expert system is not yet fielded 
in a production mode but has already paid for itself. This is 
unusual as you might guess. The reason stems from the field 
service procedure for disk drive repair. When there is a 
problem that you can't fix and the customer is staring over 
your shoulder, the unwritten rule is to do something that 
looks busy and meaningful. This means replacing the Head Disk 
assembly which takes a couple of hours and costs about $3000. 
This used to be very effective since many strange problems 
were in fact located in this assembly. Honeywell recently 
redesigned the HDA. The field service personnel were still 
employing the old word-of-mouth rule for replacing HDAs but it 
doesn't help very much. The Expert System was able to bring 
this out very clearly, at a cost savings of approximately 
$250,000. 

The keynote on Friday was given by Doug Lenat of MCC on their 
approach to overcome the brittleness barrier in knowledge 
based systems. The commercialization of AI technology began in 
the early seventies when Ed Feigenbaum of Stanford realized 
that even though no one could (or can) build an AI system to 
operate on the so called strong methods of reasoning, there 
were a wealth of applications in very narrow domains that 
could be addressed very adequately (and profitably) by the 
weak reasoning methods. This was the birth of the Expert 
System. Expert Systems are very brittle though, when based on 
these methods. The systems do not "understand" what they are 
"reasoning" about. 

For example, MYCIN, an expert system for infectious blood 
disease diagnosis, can diagnose blood diseases better than 
about 90% of the doctors it was tested against. However, if 
you told MYCIN that the patient was 7 years old and exhibited 
reddish brown skin spots, it would conclude that the problem 
was measles with some degree of certainty and recommend some 
course of treatment, even if you told it the "patient" was 
your rusting 1980 Chevrolet. This is because it really does 
not understand the concepts of disease, patient, or anything 
else for that matter. The system merely has been "told" how to 
replace variables and calculate probabilities. It has no 
"common sense". 


The CYC project at MCC is attempting to overcome this 
limitation by building a truly massive knowledge base. This 
will also aid researchers in investigating problems of scaling 
systems and has already made significant progress. This system 
is being built in several steps, in the classic AI tradition. 
The first idea was to take an encyclopedia and input it into a 
massive knowledge base. This soon proved to be infeasible 
because of the common sense knowledge knowledge required to 
understand any of the articles. The researchers discarded this 
prototype and decided to use a desktop encyclopedia, after 
first "teaching" the system what facts, rules, concepts, etc 
are. The system is progressing well and will soon enter the 
second phase in which knowledge-enterers will use the copy- 
and-edit facilities to expand the knowledge base in a massive 
manner. One of the interesting concepts in the construction of 
the KB is that CYC itself is allowed to update its knowledge 
base, thereby extending the power of the system immensely. 


AI EVENTS CALENDAR 
By Jim Sims 
May 1987 


May 13-15 

Seventh Annual International Workshop on Expert Systems and 
Their Applications - Avignon '87, Avignon, France 

New implementations, basic tools and techniques, practical 
guidelines for applications. 

Jean-Claude Rault 
Workshop Chairman 
Agence de 1'Informatique 
Tour Fiat Cedex 16 

92084 Paris-La Defense, France 331-47964314 


May 25-30 

International Workshop on Parallel Algorithms and 
Architectures, Suhl, GDR 

Thomas Zeugmann 
Mathematics Dept 
Humboldt University Berlin 
P.O. Box 1297 

Berlin 1086, GDR Telex 011 2823 
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May 27-29 

AAAI Workshop on Qualitative Physics, Univ of Illinois at 
Urbana-Champaign 

Foundational Research, Implementation techniques, 
Applications, connections to other areas of AI. 

Kenneth D. Forbus 
Qualitative Reasoning Group 
Dept of Computer Science 
University of Illinois 
1304 W. Springfield Avenue 
Urbana, Illinois 61801 


June '87 
June 4-5 

4th Annual Workshop on Theoretical Issues in Conceptual 
Information Processing, Washington, D.C. 

Exploration of issues common to representation and 
organization of knowledge and memory for natural language 
understanding, planning, problem solving, explanation, 
learning, etc. 

James Hendler 
Computer Science Dept. 

University of Maryland 
College Park, Md. 20742 


June 22-25 

Second Annual Symposium on Logic in Computer Science, Ithaca, 
N. Y. 

Abstract data types, foundations of logic programming, 
software specifications, logic-based languages, logic in 
complexity theory. 


David Gries 
Program Chairman-LICS 
Dept, of Computer Science 
Cornell University 

Ithaca, N.Y. 14853 (607) 225-9207 


June 28-July 1 

ACM/IEEE Design Automation, Fountainbleau Hilton Hotel, 
Miami, Fla 

Design Automation Conference 
1730 Massachusetts Ave., N.W. 

Washington, D.C. 200036-1903 (202) 371-0101 


July '87 
July 12-18 

AAAI-87 Sixth National Conference on Artificial Intelligence 
Seattle, Washington 

AAAI-87 

American Association for Artificial Intelligence 

445 Burgess Drive 

Menlo Park, Ca. 94025-3496 


July 13 

Blackboard Systems: Implementation Issues, Seattle, Washington 

Invited workshop on blackboard systems implementation issues; 
Control issues, Organization issues, Parallelism, Performance, 
Development environment. 

Workshop Chair: 

V. Jagannathan 
MS 71-64 

Boeing Advanced Technology Center 
Boeing Computer Services 
P.O. Box 24346 

Seattle, Washington 98124-0346 (206) 865-3240 


July 16 

Workshop on Planning for Autonomous Mobile Robots, University 
of Washington, Seattle, Washington 

This workshop will discuss planning and knowledge requirements 
of an autonomous exploratory robot, such as Mars Rover. The 
topics include: Spatial Rep, Risk Analysis, Planning in 
Dynamic domains, Map Building, Spatial and Temporal Reasoning, 
Physical Reasoning, Planning under Uncertainty, Experience 
based Planning, Sensor Coordination, and Route Planning. 


AI-7 


AI-8 



CFP to: 


NEW AI SOFTWARE AVAILABLE FOR VAX HARDWARE 


David P. Miller 
Dept, of Computer Science 
562 McBryde Hall 
Virginia Tech 

Blacksburg, VA. 24061 (703) 961-5605 


August '87 
August 23-28 

IJCAI-87 10th International Joint Conference on Artificial 
Intelligence, Milan, Italy 

Conference Information: 

Alan Bundy 

Dept, of Artificial Intelligence 
University of Edinburgh 
80 South Bridge 
Edinburgh, EHllHN, UK 


September 1987 
September 21-25 

European Congress on Simulation Conference and Exhibition, 
Prague, Czechoslovakia 

ECS '87 

c/o Director , Institute of Computer Sciences 
Czeckoslovak Academy of Sciences 
182 07 Prague 

P.O. Box 5, Czeckoslovakia 846669 


October 1987 
October 5-7 

AAAI Spatial Reasoning and Multi-Sensor Fusion Conference, 
Pheasant Run Resort, St Charles, Ill. 

Spatial Reasoning, Multiple sensor inputs, Spatial Planning, 
Formal Theory, Fusion of sensory inputs, Evidential Reasoning. 

CFP to: 

Su-shing Chen 
Dept of Computer Science 
University of North Carolina 
Charlotte, NC 28223 


By Terry C. Shannon 

CAMBRIDGE, MASS— Heralding a move from dedicated AI hardware 
into the mainstream data processing marketplace, AI software 
vendor Applied Expert Systems, Inc. (APEX) has announced the 
availability of APEX Client Profiling, a sophisticated 
VAX-based AI software package designed to help insurance 
agents tailor financial packages to meet the needs of 
potential clients. 

According to APEX public relations specialist Lynn Smith, the 
Client Profiling System gives insurance companies, banks and 
other financial institutions a new means to provide their 
field agents with expert advice. The Client Profiling 
software, which incorporates the expertise of tax, investment, 
estate, retirement and insurance specialists into a 
knowledge-based expert system, runs in batch mode on DEC 
VAXes, with remote data entry from an IBM PC-compatible 
microcomputer. 

The development of an AI application that runs on conventional 
hardware instead of a dedicated symbolic processor is a first 
for the Cambridge software developer. APEX'S first product, 
Planpower, is a Lisp-based expert decision support system that 
runs on dedicated Xerox AI workstations which rely software 
hooks to access information stored on corporate mainframes. 

The Client Profiling system, by contrast, relies on a 
VAX-resident expert system module to more tightly integrate AI 
capabilities with conventional data processing resources. 
Jointly developed with a major insurance company, the Client 
Profiling System uses knowledge-based intuitive processing to 
match corporate product and marketing strategies to specific 
client needs and objectives. Because the software helps field 
agents better understand client's needs, institutions can 
design and offer a broader range of financial products to its 
customers. 

Noting that the Client Profiling system can process at least 
1,000 individualized recommendations per month, Smith 
maintained that the new software is a strategic asset that can 
help a firm broaden its market share by increasing the number 
of customers it services without a corresponding personnel 
increase. 

To use the Client Profiling system, a field agent enters the 
client's financial information on a personal computer at the 
field office. After the information is uploaded and processed 
on the VAX-resident Client Profiling system, the agent 
downloads a presentation-ready file containing 15 to 20 pages 
of customized financial recommendations for the client, as 
well as a suggested sales strategy that reflects the client's 
situation. 
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Smith contrasted APEX'S new knowledge-based software package 
with traditional decision support programs by emphasizing the 
specificity of the information provided by the Client Profiling 
system. "Unlike conventional financial planning software 
packages which analyze needs and make generalized 
recommendations, the Client Profiling system takes into account 
expressed customer priorities and develops specific 
recommendations supported by clear implementation strategies," 
Smith said. 

The Client Profiling system is currently in field test and 
customer installations are expected to begin in May 1987. 
Applied Expert Systems is located at Five Cambridge Center, 
Cambridge, MA 02142. 
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FROM THE EDITORS — Bill Walker/Carmen Wiseman 


HARDWARE HINTS AND KINKS 


DEADLINE FOR THE NEXT ISSUE: 2 4 MAY 1987 

For some reason, the bulk of this issue of the newsletter emanates 
from Ohio — March must be a slow time in the rest of the country. 

Since we didn't have a large volume of material this month, I had 
the time to do a little bit of clean-up. The "Hardware Submission 
Form" is back — slightly revised. It is in the "Questionnaire" 
section of the combined newsletters (it disappeared a few months 
ago for some reason). If you have a short note, a "war story" or 
just a problem that has you stumped, you can send it in on this 
form. 

Also, I would like to remind everybody (hint, hint) that there are 
many other ways to send material in to the HMS SIG Newsletter. If 
you flip back to the "How To" section, you will find a description 
of several methods to get stuff to either myself or Carmen. Basi¬ 
cally, if you write it, we'll figure out some way to get it in 
print. 

— Bill Walker, Editor 


CALL TO NASHVILLE PRESENTERS! 

If you gave a hardware-related session at DECUS South in Nashville, 
why not send us an article summarizing your presentation for publi¬ 
cation in the HMS SIG Newsletter? 

Actually, we're not just begging for material here! Spreading in¬ 
formation, particularly information that only hard-won experience 
can provide, is what an organization like DECUS is all about. The 
HMS SIG Newsletter is a very effective channel for disseminating 
such information: It reaches a lot of people, including DECUS 
members who don't have the time or the bucks to attend both na¬ 
tional symposia every year. You'd be doing those folks a real 
favor by publishing an article giving the high points of your talk. 

The stuff you send us doesn't have to be too long, but it should 
contain more detail than the synopsis in the program book. If 
you're self-conscious about your literary talents or feel you just 
don't have the time to reconstruct your notes, relax! You can send 
in your raw, seething index cards or overheads, and we'll take care 
of cooking it all up into a legible article for the newsletter. 
(The important thing is substance, not style.) We'll gladly return 
any graphics or other materials when we're through with them. 

If you have any questions about submitting a presentation article, 
give me a buzz at (617 ) 375-4361 between 9 a.m. and 6 p.m. EST. 

— Carmen D. Wiseman, Assistant Editor 


BA23 Power Cable Problem 

[Terry Compton submitted this note over CompuServe. — Ed.] 

This month's service fiche lists a problem with all BA23-Ax and 
BA23-Bx boxes. I would assume that this information would also ap¬ 
ply to all products that use the BA23 like MicroVAXen, and VAXsta- 
tions. 

It seems that the connectors on the DC power cable from the power 
supply to the backplane are underrated to carry the current in¬ 
volved. The current rating of the components involved were derated 
by the manufacturer. 

This could result in overheating of the connector and possible sys¬ 
tem failurp. The original cable is part number 70-20450-01; it 
has been replaced by part number 17-01311-01. You can also order 
the entire FCO for this fix, which is part number EQ-01427-01 for 
the FCO instructions with parts, or FA-04712-01 for the FCO only. 

If you want DEC to come out and take care of this problem for you, 
they will be glad to—at "the then current hourly rate". 

Terry Compton 
Comp3, Inc. 

2500 Onyx Ct. 

Grove City, OH 43123 


Using An LA120 As Operator's Console 

[Steve Murphy sent in the following note. He is using an 11/34A 
running RSX-llM V4.2D. — Ed.] 

Warning: If you have an LA120 as your operator's console and it is 

on a switchable power source, the boot PROM code execution will be 
confused with the following results: 


1. The registers will not be printed on the console at 
powe r-up. 

2. Tapes which are normally bootable on MT: and MU: devices 
(TE10-W and TK50) will no longer boot. 

Fix: Put LA120 on a nonswitchable line. 


Steve Murphy 

Goodyear Aerospace Corp. 
1210 Massillon Road 
D/691 B/2 
Akron, OH 44315 
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CONTRIBUTION GUIDELINES 


From the Editor's Terminal 


Contributions for the newsletter should be sent to: 

Frank R. Borger 
Michael Reese Medical Center 
Department of Radiation Therapy 
Lake Shore Drive at 31st St 
Chicago, IL 60616 


Contributions of letters, articles, important SPR's etc will be 
accepted in any form, (including notes jotted in pencil on 
gravy-stained tablecloths.) Contributions will be much more gra¬ 
ciously accepted in one of the following formats: 

1. Non machine readable sources, (SPR's etc,) should be reason¬ 
ably dark to insure good photocopying. Text whatever should 
be the equivalent of 66 lines at 6 lpi, with 4-line top mar¬ 
gin, 5-line bottom margin, left-margin 10, right margin 74 
at lOcpi. If using a DEC LN03 for output, use left-margin 8. 
right margin 72. 

2. Machine readable sources may be submitted on 9-track 

Mag-tape, (800,1600, or 6250 BPI,) DEC-tape II, DecMate 
floppies, or whatever. We're not fussy, we'll even accept 
paper tape or cards. Preferred format is DOS or BRU for 
tapes, Files-11 for DEC-tape II. 

3. 1200 baud dial-up modems are available on our IAS system and 
our VAX, with various servers available. Give the editor a 
call at (312)—791—2515 (preferably later in the day,) to ob¬ 
tain access information, etc. 

4. If long distance dialout is not possible on your system, 
we'll be willing to call your system and do the work, (un¬ 
less you want to transfer the entire manual set at 300 
baud. ) 


Any media sent to us will be promptly returned. 


ASK THE DEVIAS WIZARD 


If you have a problem you would like to submit to the Devias 
wizzard, write a letter or fill out a copy of a standard SPR and 
send it to the Editor at the above address. Answers to problems 
from members (or anyone) should also be sent to the Editor. 
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Spring is finally here, (as I write this,) and with it Spring 

DECUS is fast approaching, (or just over as you read this.) In 
any case, it has prompted your editor to get himself involved in 
a couple more projects (as if I didn't have enough to do alrea¬ 
dy.) They should be of general interest to IAS enthusiasts. 

Your editor has agreed to be a test site for Update D. We will 
attempt to provide information to users about the Update, and 
hope to get feedback from any other brave adventurers that DEC 
has talked into being a test site. 

Through the kindness of Brian Nelson, we received a full set of 
sources for Bruce Wright's modifications to RSX kermit to allow 
it to run under IAS. See the following article for more infor¬ 
mation . 

This month's program of the month is a simple one to program the 
programmable keys of a VT220 terminal. Before you try it on 
your system, be aware that we use a brand-x 220 clone that sup¬ 
ports programmable unshifted as well as shifted keys, (which I 
believe the 220s SHOULD also do,) so be aware that you won't be 
able to re-define the non-shifted function keys on a real VT220. 

Much talk has been floating around the SIGs lately about forming 
a combined PDPll user's sig. The idea is that the VAX SIG has 
more impact on DEC due to its size, while the smaller 11 based 
SIGs don't get enough recognition, and that all the 11 users, if 
banded together, would provide a much more unified front. DEC 
seems to be ignoring the PDPlls lately, (face it, VAXes sell for 
a lot more that 11s.) 

Your editor feels somewhat ambivalent. I am already closely in¬ 
volved with GRAPHICS, HMS, VMS, IAS, RTll, DATATRIEVE/4GL, RSX, 
(probably soon to be a full system, not just the VMS emulator,) 
and believe that there's nothing wrong about a small SIG or 
right about a large one. I do feel miffed when my paper on a 
home grown BASIC interperter (written in machine language,) is 
heard by 25 people, while down the hall 300 people are avidly 
listening to someone talk about "programming" in DCL on their 
VAX. TANJ. 

If any of you out there have strong (or even weak) feelings 
about whether or not its time to circle the wagons and battle 
the cats, please write. 


Summer is only 7430400 clock ticks away, (6192000 in Europe.) 


IAS- i 


IAS-1 



Ten Years Ago Today 


The May 1977 Multi-Tasker contained: 

A long discussion concerning problems with SPR reporting. It 
first gave DEC'S list of 8 reasons why a SPR would not be pub¬ 
lished in the dispatch. 

1 SPR was for an unsupported version of the software. 

2 Problem showed user did not apply previous fixes. 

3 SPR attachment is unreproducable or too long. 

4 Problem has been previously published. 

5 Problem is unclear and could cause confusion to readers. 

6 SPR is marked "Do not publish." 

7 Problem is considered to be of limited interest. 

8 SPR is a "Suggestion only." 

A survey of 44 SPRs sent to the SIG since the first of the year 
showed that only 5 had made it to the Software Dispatch. The 
Software Communications office was "Researching the 39 (other) 
SPRs to determine exactly how they were disposed of and what re¬ 
asons were given for non-pubication. (I would be surprised if 
the percentages have changed much in the last 10 years, ed.) 

George Hamma (of the BAYLUG, ) had a nice table comparing 11M 
version 2 versus 11D version 6, showing what 11D system direc¬ 
tives were fully supported, and which ones were not supported, 
or weren't supported in all three forms, ($, $C and $S.) It was 
a nice guide on how to develop code on larger llD systems that 
would run on smaller 11M systems. (Quite the reverse of today's 
conditions, as we wait for RMS version 2 ed. ) 

Rebuttal, support and comments followed concerning the upcoming 
question of charging for the SIG newsletters. (The more I 
re-read the discussions and squabblings that were going on 10 
years ago, the more I appreciate the simplicity of the single 
SIGs newsletter, ed.) 

Chapter happenings reported that a Pacific Northwest Real-Time 
LUG had been formed, with Ray French as co-ordinator. 

Finally: a forum article that probably should have been on the 

editorial page by Mark Lewis deplored the "new DECUSSCOPE" for¬ 
mat. He felt that the emergence of the SIG newsletters as the 
primary means of distributing system or application specific 
technical articles had left DECUSSCOPE with "A tone that is not 
dissimilar from the public relations pap that issues forth from 
Digital at similarly infrequent intervals." 
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MICHAEL REESE MEDICAL CENTER DEPARTMENT OF MEDICAL PHYSICS COMPUTER 


LISTING OF DR2:[102,006]TVEDT.BAS ON 27-MAR-87 AT 15:48:19 PAGE 1 


810 REM SET TELEVIDEO FUNCTION KEYS FOR EDIT 

11 DIM A$[3],B$[100]V,c$[100]v,hx$[16] 

12 PRINT CHR$(27): break 

13 print CHR$ (27);"[63;1";chr$(34);"p"; : BREAK 

14 print chr$(27);"P0;1|";chr$(27);"\"; : break 

16 pr$=chr$(27)+"0P"+chr$(27)+"0"+chr$(119) 

17 fo$=chr$(27)+"OM" 

18 hx$="0123456789ABCDEF" : cr$=chr$(13) 


vt52>vtl00 mode 
vtl00>9220 mode 
clear fn keys 
ked cmd prefix 
ked cmd trailer 


20 ky$="37" 
30 ky$="38" 
40 ky$="39" 
50 ky$="40" 
60 ky$="41" 
70 ky$="43" 


b$="BAS SD:[102,1]PROFF/RN"+CR$ : gosub 2000 
b$="BAS SD:[102,1]PRON/RN"+CR$ : gosub 2000 
b$=pr$+"OP OU " : gosub 2000 
b$=pr$+"WR SEL"+fo$ : gosub 2000 
b$=pr$+"WR RES"+fo$ : gosub 2000 

b$="TER /NOSFF"+CR$+"PIP TI:=SD:[102,1]FF."+CR$ : 


b$=b$+" TER /SFF"+cr$ : gosub 2000 


80 ky$="44" : b$=pr$+"CL 
90 ky$="45" : b$=pr$+"EX 
100 ky$="46" : b$=pr$+"Q 

110 ky$="51" : b$="BAS S 

120 ky$="52" : b$="@SD:[ 

130 ky$="53" : b$="BAS S 

140 ky$="54" : b$="BAS S 

150 ky$="17" : b$="DAMMIT"+CR$ : gosub 2000 

160 ky$="18" : b$="COOKIE"+CR$ : gosub 2000 

170 ky$="19" : b$="MURPHY"+CR$ : gosub 2000 

180 ky$="20" : b$="MAY"+CR$ : gosub 2000 

190 ky$="21" : b$="BAS SD:[102,1]TIMSPOT/RN"+CR$ : gosub 2000 

200 ky$="23" : b$="VDI"+CR$ : gosub 2000 

210 ky$="24" : b$="DIR"+CR$ : gosub 2000 

220 ky$="25" : b$="VTL " : gosub 2000 

230 ky$="26" : b$="@LB:[1,1]RUN"+CR$ : gosub 2000 

240 kv$="31" : b$="WHO"+cr$ : gosub 2000 

250 ky$="32" : b$="@SD:[102,1]MEDT"+cr$ : gosub 2000 

260 ky$="33" : b$="WHERE" + cr$ : gosub 2000 

270 ky$="34" : b$="WHN"+cr$ : gosub 2000 

280 print chr$(27);"(B"; :! select uaascii as primary char set 

290 print chr$(27);")O"; :! select graphics as second, char set 

300 print chr$(15); :! turn on primary char set 

310 print chr$(27);">"; : break :! select numeric key pad 

315 ! Following line commented out to stay as a TV9220 

320 ! print CHR$(27);"[61";chr$(34);"p"; : break:! back to vtlOO 

330 exit 

2000 c$-chr$(27)+"Pl;l|"+ky$+"/" 

2010 for j=l to len(b$) 

2020 x=asc(sbs$(b$,j,1)) 

2030 xh=int(x/16) : xl=x-xh*16 

2040 c$=c$+sbs$(hx$,xh+l,l)+sbs$(hx$,xl+l,l) 

2050 next j 

2060 c$=c$+chr$(27)+"\" 

2070 print c$; : break 
2080 return 


b$=pr$+"CLOSE"+fo$ : gosub 2000 
b$=pr$+"EXIT"+fo$ : gosub 2000 
b$=pr$+"QUIT"+fo$ : gosub 2000 
b$="BAS SD:[102,1]TVEDT/RN" + cr$ 


b$ = "@SD:[102,1]MKED" + c r$ : gosub 2000 


gosub 2000 


b$="BAS SD: [102,1]TV9220/RN"+cr$ 
b$= "BAS SD: [102,1]TVONE/RN"+cr$ : 


: gosub 2000 
gosub 2000 
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IAS Kermit Lives 

In a recent issue, your editor asked about interest in support¬ 
ing KERMIT on IAS. As a result of that question, Brian Nelson 
and I got together over the phone and discussed Bruce Wright's 
implementation of the RSX KERMIT under IAS version 3.1. The 
problems with that version (as distributed on the sig tapes,) 
are as follows: 

1. The programs were linked to a version 3.1 RMSRES resi¬ 
dent library, so unless you were running the same ver¬ 
sion and update as the EPA, the task image was unus¬ 
able. 

2. No sources or objects were provided. 

3. Brian Nelson had no access to an IAS system to do up¬ 
dates, etc. 

Brian was kind enough to send us the full IAS package from the 
EPA, and we have committed ourselves to supporting the IAS ver¬ 
sion. (A trivial bit of work compared to the amount of work 
Brian has poured into creating a unified RSX, RSTS, RT package. 
- - - Thanks Brian.) 

At the present time we have brought the 3.1 version up under 3.2 
and made some minor modifications and bug fixes. Our further 
goals are to get the IAS version in step with Brian's develop¬ 
ment, and to include fixes to limitations, (lack of RMS version 
2 support, terminal handler limitations, etc.) when IAS enhance¬ 
ments permit. 

The following will summarize the modifications and bug fixes we 
made to KERMIT IAS. 

1. Under 3.1, a QIO dpb of the form 

IODPB: QIOW$ io.wvb,5,1, ,,,<pl> 

generated a DPB with all 6 parameters, (five of them 
null.) If your code filled in the length of transfer 
later... 

mov #size,iodpb+q.iopl+2 

everything worked fine. 

Under 3.2 however, the QIO macro has become more intel¬ 
ligent. Its smart enough now to only allocate pi. Now 
your code slaps the io transfer size on top of the next 
thing in your program, and to add insult to injury, the 


QIO directive is now rejected because the DPB has an 
improper size. (Isn't it wonderful what a little IM¬ 
PROVEMENT will do?) 

2. Under IAS version 3.2, our TKB seems to have a bug in 
that it no longer sets up the low memory pointer $VEXT 
(the vector extension area pointer.) This cause the 
RMSll init code to bring kermit to a crashing halt. A 
patch was added to module K11M41 to set up this area 
properly. 

3. Since we have modem lines that are use both for dialin 
and dialout, we changed the connect code to change and 
restore the terminal characteristics Full-duplex and 
Binary while in connect mode. 

4. Due to IAS kermit having to do character at a time IO 
on incoming data, kermit only worked at 300 baud. Code 
has been added to the connect code to support control-S 
control-Q throtteling of incoming data. (It is assumed 
that this will become simpler with the terminal handler 
update that supports automatic control-S control-Q done 
by the handler in response to the size of the 
read-ahead buffer, and will go away if the capability 
of reading the number of characters in the read-ahead 
buffer ever gets into the IAS handler.) The response is 
jerky, and nowhere near 1200 baud, but its better than 
300 any day. 

5. The kermit SYS command, (which let you Spawn a system 
command without leaving kermit,) was modified to try to 
call a command line munger or flying install task if 
the ...NAM or $$$NAM task spawn failed. 

Working 3.1 and 3.2 versions will be submitted to the Spring SIG 
tape, and anyone with a desperate need can get copies from us if 
you give us a call. 
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Contributions 


Contributions and suggestions for this newsletter are constantly needed. Articles, 
letters, technical tips, or anything of interest to our SIG are greatly appreciated. The 
editor prefers submissions be made electronically, but magnetic tape and hard copy will 
be accepted. 

Send your contributions to: 

ARPA: ctp@sally.utexas.edu 

UUCP: ctp@ut-sally.uucp ({harvard,ihnp4,seismo}!ut-sally!ctp) 

CIS: 75226,3135 

BITNET: use the Wisconsin Gateway 
or if you must, use the U. S. Mails: 

Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin, Texas 78712-1188 


History Project, Digital’s 36 Bit Systems 

Les Earnest and Joe Dempster 


The goal of this project is to publish an analysis and history of the evolution, imple¬ 
mentation and use of Digital’s 36 bit systems. This period began with the PDP-6 in 1964 
and continues today with TOPS-10/20 development, which is scheduled to end in 1988. 

We are working aggressively to finish the project, and have it published, by March/ 
April 1988. This will require that the completed manuscript be ready to go into the 
publication cycle by August 1987! 

The project will attempt to answer the following questions: 

1. In what markets/applications were these systems used? 

2. Who were the users of these systems and what impact did roughly 2,500 TOPS-10/20 
systems have on their organizations? 

3. Who were the principle system architects of these systems? What features, and if 
there had been sufficient time to implement them, would have significantly improved 
the architecture? 


4. What impact did the decision to continue to examine design extensions to the archi¬ 
tecture have on the usefulness and acceptability of these systems. This is in contrast 
to a more common practice today to work from a detailed design specification, some¬ 
times dated, building follow-on systems which provide increased performance through 
the use of new component technologies and packaging techniques. 

5. What part of the overall design (TOPS-10/20) was technology dependent and what 
can still be considered “unequaled” in relation to other computer architectures still 
undergoing active development? 

6. What type of development environment (both HW and SW) supported and con¬ 
tributed to the evolution of 36 bit systems? 

7. What influence did TOPS-10/20 have on other vendors system development? 

This history will undoubtedly be assembled from many sources and participants. 
Some information will be anecdotal; there will be interviews with the people involved 
(users and developers) and technical papers will be solicited. Of course there will also be 
the packaging and assembly of facts as we see them. 

The result will hopefully have sufficient depth to serve as: 

1. An introductory or advanced text on system design and hardware/system software 
implementation. 

2. A analysis of the success and difficulties of marketing complex systems into a very 
crowded market of competing alternatives. 

3. A catharsis for those of us who have contributed to the development and use these 
systems and who will now move onto new computing architectures and opportunities. 

In addition to interviewing directly 25-50 developers, users and product managers we 
will continue to work to identify contributors and significant events up to when the final 
draft is submitted to the publisher. Two “topics” are already under development: 

1. Rob Gingell from SUN is working on a paper which looks at extensions to TOPS-20 
which would have enhanced its capabilities. 

2. Frank da Cruz and Columbia are summarizing 10 years of experience and development 
of TOPS-20 systems. Some effort, will also be made to detail the process which lead 
to their selection of a follow-on architecture to TOPS-20. 

There is a need to develop additional topics which represent the use and application 
of the technology (TOPS-10/20) in other areas. Specific recommendations are welcome 
as are proposals to develop them. A short abstract should accompany any such proposal. 
Every effort will be made to work with individuals or organizations interested in making 
such a contribution. 

There will be a standalone (no network connections) DECSYSTEM-2020 (YIPYIP) 
dedicated to supporting the project. This system has a 3 line hunt group, with all lines 
accessible from a single number ((201) S74-8612). 

Both YIPYIP and MARKET will have “public” directories for remote login (<log> 
DEMPSTER.PROJECT-10262 <Password>LCGLCG). MARKET can be accessed by 
modem ((617) 467-7437), however disk quota, is limited. MARKET’S primary purpose 
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<DEMPSTER.PROJECT-10262> is ARPAnet TELNET access. YIPYIP is a dedicated 
PROJECT-10262 system. MAIL can also be sent to DEMPSTER on either system. 

YIPYIP and MARKET will keep a running summary of ideas and comments up on 
Columbia’s BBOARD software. KERMIT also runs on each system for uploads. 

SAIL.STANFORD.EDU will support ARPAnet transfers to a “public” area: 
FTP<ret> 

CONNECT SAIL.STANFORD.EDU<ret> 

SEND AFN.EXT<ret> 

DSK: AFN.EXT [PUB,LES] <ret> 

SAIL runs WAITS, an operating system similar to TOPS-IO. File names are limited 
to 6 characters and extensions limited to 3. 

Hardcopy information may be sent to the authors at the following addresses: 

Les Earnest 

Computer Science Department 
Stanford University 
Stanford, CA 94305 
(415) 723-9729 

ARPA: LES@SAIL.STANFORD.EDU 
Joe Dempster 

Digital Equipment Corporation 
6 Cherry Hill Executive Campus 
Route 70 

Cherry Hill, NJ 08002 
(609) 665-8711 

ARPA: DEMPSTER@MARLBORO.DEC.COM (MARKET) 
Implementation details: 

1. User input is welcomed and desired from all application and geographic areas. 

2. Input from past and present developers is also desired. 

3. Throughout the project a secondary goal will be to build a list of users/locations (in¬ 
stallation date, duration and disposition) of PDP-6 and KA, KI, KL and KS systems. 
Serial numbers, if available, are requested. 

4. We anticipate that this project will generate a large volume of information (which 
we hope will arrive electronically). Some information, for any number of reasons, 
may not be in line with the project’s stated goals. Therefore, all notes, interview 
material and submissions will be donated to the Computer Museum in Boston at the 
the completion of the project to be available for future reference and research. 

Ideas, contributions, suggestions and criticism are welcome. As these 36 bit systems 
were the products of a multitude of people, so too will be the writing of their history. 


From the TOPS-20 Mailing List 

Abstracted by: Clive Dawson 


The following messages are selections taken from the TOPS-20 interest group, which 
is a mailing list maintained on the DARPA Internet. These items appear for information 
purposes only. Neither DECUS nor the authors assume any responsibility regarding the 
usefulness or accuracy of the information herein. 


Date: Mon, 23 Feb 87 17:27:40 PST 

From: Mark Crispin <crispin@SUMEX-AIM.Stanford.EDU> 

Subject: bug in GTHST% JSYS 

This bugfix should be considered a MUST INSTALL for all TCP/IP sites running 
with multiple interfaces. I wrote the original code, so I know what I’m talking about. 
I would appreciate an acknowledgement from DEC that it has been TCO’d into DEC’s 
TCP/IP-20 product. 

Problem: 

Stange behavior in mailsystem, with valid mailing lists rejected as “No such directory 
name” 

Diagnosis: 

MMailbox fails to recognize that an address is local, and doesn’t recurse on it during 
mailing list expansion. This is caused by the monitor being confused when the default 
address occurs after the preferred address in the host table. GTHST% always returns 
the preferred address when the local host (-1) is given as a host argument. An erroneous 
test is made that allows the default address to supercede the preferred address in this 
case. 

Solution: 

In MNETDV.MAC, at HSTI13+6, delete the two lines: 

CAMN T1,DEFADR ;0UR DEFAULT ADDRESS IS ALWAYS BEST 
JRST HSTI15 ;SO SET IT AS BEST UNCONDITIONALLY 


You may also want to change the comments on the next two lines to be: 

CAMN T1,PRFADR ;OUR PREFERRED ADDRESS IS ALWAYS BEST 
JRST HSTI15 ;SO SET IT AS BEST UNCONDITIONALLY 


That is, the fix is only to allow the ***PREFERRED*** address to be unconditionally 
selected as the best address. 

- Mark - 
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Date: Sat 28 Feb 87 15:03:37-PST 

From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU> 

Subject: DIRFDB bugchks 

Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 
Phone: +1 (415) 968-1052 

In DIRECT.MAC, the instruction at DELJF2 should be CALL ADRCHK, not CAMGE 
A,DIRORA. 

Be sure to also have the patch in LOOKUP.MAC to do MOVE A,B before the JUMPE 
A,R in the GETFDB routine (after the CALL VERLKX succeeds). 

By the way, the comments in the code in these areas are total lies. Don’t believe any of 
them. Fortunately, it isn’t executed very often. 


Date: Sun 1 Mar 87 16:17:26-EST 

From: C. P. Yeske <CY13@TE.CC.CMU.EDU> 

Subject: RP07 revisited 

Home-Phone: (412)422-4667 (422-GOOP, -IONS, -HOOP) 

Office: UCC A72 x2647 

Organization: Carnegie Mellon Computing Center, Hardware Systems 

As promised, a digestified answer is below. Basically the rumor is false. My thanks 
to all those who replied. 

Curt Yeske 

Technical Administrator 
Carnegie Mellon Computing Center 
CY 13@te.cc.cmu.edu 

Disclaimer: The opinions expressed are my own and are not Carnegie Mellon’s. The 
facts are figments of my imagination anyway. 

*** My message *** 

Currently we have some RP07’s formatted for VMS and several formatted for Tops. 
We would like to be able to interchange these from time to time as hardware konks out. 
I am aware that each system needs to see its own formatting (36 bit vs 32 bit). We are 
aware of how to format each type. However we have heard a rumor that it is not possible 
to take a Tops-20 formatted RP07 and reformat it for use on a Vax. Can anybody confirm 
or deny this? 

Please let me know and I will digest the answers back to info-vax and tops-20. 

*** Exact Information *** 

>From: Willis Dair <G.Dair@Score.Stanford.EDU> 

Your rumor is wrong. The RP07 has the capability to format itself to 18-bit (TOPS- 
20) or 16-bit (VAX). The little microprocessor inside will do the actual formatting. Your 
local field person should be able to do the formatting. We have some TOP-20 RP07 disks 
that were converted to be VAX disks. These are pretty smart drives. 

Willis 


*** Exact Information *** 

>From: Carl Fussell <G.FUSSELL@Score.Stanforcl.EDU> 

That is not true. We have two RP07s that were running on our TOPS20 there were 
reformatted (on site) and are now running on our VAX/VMS system. The operation 
amounts to removing a jumper from the backplane of the drive and then formatting. 

Carl Fussell 

*** Other information *** 

>From: “ROBERT CURLEY” <curley@wharton-10> 

I recently purchased the RP07 from the Medical School Computer Facility here at 
Penn. It had been connected to a DEC10. I wanted it connected to my 780. During 
the installation process the Field Service person mumbled something about the format 
problem - but overcame it. I will ask him about the details if you wish. 

*** Other *** 

>From: <SYSTEM@CRNLNS.BITNET> 

Curt, 

I don’t know about TOPS-20 format packs, but we had no trouble at all when con¬ 
verting our RP07 first from VMS format to TOPS-IO and later from TOPS-IO format 
to VMS format. In addition to a different block size (TOPS-IO has 128 36bit words per 
block: 640 bytes instead of 512) the disk was formatted without interleaving while we 
used it on the 10, but we are using it with interleaving on our 8600. 

As I recall, the DEC VAX diagnostic that did the reformatting had to run stand-alone 
because of the stringent timing requirements. 

I hope this helps. 

Selden E. Ball, Jr. 

*** Other Information *** 

>From: 114RONAN%UK.AC.LIVPOL.VAX@AC.UK 

Hi. Sorry I can’t really help you with your RP07 problem, but we had an RA81 
delivered for our VAXcluster which had been formatted for 36 instead of 32 bits, and we 
had to wait weeks while DEC took it back and got another one - they did NOT re-format 
the original, so maybe it’s a hardware thing. 

On another topic, I notice that your message was also sent to TOPS-20 at Stanford. 
Can I assume that this is a TOPS-20 version of INFO-VAX? If so, how can I get myself 
registered on it? We also have a 2065, and if TOPS-20 is anything like INFO-VAX, it 
will prove a fountain of useful information. I presume there would be no problem getting 
messages through to here in the U.K.? 

[try TOPS-20@SCORE.STANFORD.EDU -curt] 

Ronan Flood 
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*** Other Information *** 

>From: lsmith.pasa@Xerox.COM 

This is not a direct answer to your question of can you reformat an RP07. However, 
we were faced with getting data from a DEC10 RP06 disk to a VAX and solved it by 
using a dual-access RP06 disk drive and developing code to run under TOPSIO to access 
the RP06 in the VAX’ Files-11 format. We were thus able to format the disk from the 
VAX, then dismount it from the VAX, mount it from the DEC10, write DEC10 files to it, 
dismount from DEC10, mount from VAX and read the data. If you’d like further details 
let me know. Leigh Smith 


Date: 13 Feb 87 18:53 +0100 

From: JanJMichael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA 

Subject: DECnet SINR%, SIBE%, and MTOPR% .MORLS problems with zero-length 

record. 

I’m trying to read from DECnet (SRV: or DCN:) asyncronously, using the interrupt 
system. Everything works fine, until I receive a zero-length record. This is what happens: 

1) I get the interrupt, as usual. During the interrupt I must read ALL the records 
queued up for me, or I will not get any more interrupts. 

2) I check the link status with the MTOPR% function .MORLS, which returns with 
MO%EOM set (link has entire message to be read). 

3) I check the number of bytes in the message with SIBE%, which skips, returning 0 
(SIBE% seems to return the number of bytes in the next record, not the total number 
of bytes). Is this a correct behaviour? Though the next record is zero-length the input 
buffer is not empty really. 

4) I read the record with SINR% (negative count and byte pointer don’t change, indi¬ 
cating zero length). 

5) I check the link status with the MTOPR% function .MORLS, which again returns 
M0%E0M, whether there is more to read or not. THIS IS A BUG. 

6) Once again I check the number of bytes to read, with SIBE%, which again skips, 
returning -1 (minus one byte!?), whether there is more to read or not. THIS IS 
ANOTHER BUG. 

Reading a zero-length record screws up TOPS-20 DECnet, but everything gets back 
to normal after reading the next record, whether that is also zero-length or not. 

My problem is that I can’t determine if there is anything more to read after reading 
the zero-length record. If I try to read another record with SINR% I will hang until I 
receive another record of input. If I don’t try to read another record and there is one I 
woun’t get any more interrupts. Any suggestions? 

According to the TOPS-20 Monitor Calls Reference Manual, SIBE% should not skip 
if "The device is not a terminal, is open for read, and the input buffer is not empty. AC2 
contains a count of the bytes remaining in the input buffer.” This indicates that SIBE% 
should really take the non skip return, with a zero in AC2, if the next record to be read is 
zero-length. The current behaviour of SIBE%. not being able to differ between the next 


record being zero-length and an empty input queue, is both impractical and contrary to 
the documentation. It should be changed. 

MTOPR% function .MORLS returning MO%EOM, when there is nothing to read, is 
a bug which should be corrected. 


Date: Mon 2 Mar 87 10:36:40-PST 

From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU> 

Subject: Re: DECnet SINR%, SIBE%, and MT0PR% .MORLS problems with 
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 
Phone: +1 (415) 968-1052 

It isn’t at all clear that using the interrupt system to do asynchronous I/O is the 
way to go. It is easily possible for PSI’s to be doubled or missed entirely under the right 
conditions. 

The standard way of doing this is to have two forks running, one handling input and 
one handling output. Then you can let the input fork block to its heart’s content without 
hanging the other fork. You also guard against deadlocks that are caused by attempting 
to do output that won’t go through until you do input. 

- Mark - 


Date: Mon 2 Mar 87 19:38:49-PST 

From: Stu Grossman <GROSSMAN@Sierra.Stanford.EDU> 

Subject: Re: DECnet SINR%, SIBE%, and MTOPR% .MORLS problems with 

Mark, 

I don’t think that his problem has anything to do with PSIs. From his description 
of the problem he is not doing anything inherently incorrect. As long as he attempts to 
empty the input queue before DEB Riving, he should wake up at the correct time. Even 
if the queue becomes non-empty between the time he checks it (with an MTOPR) and 
the DEBRIv, DECnet will still deliver a PSI to him. 

The 'standard way’ you talk about is may be your standard way to drive input 
and output streams, but it ain’t necessarily mine, or anybody elses. I have seen (and 
used) quite a few techniques to accomplish the goal of driving seperate input and output 
streams, and the method you mention is no more standard than any of the others. If I 
really wanted to be picky, I could talk about the system impact of running the streams 
in seperate forks versus internally timesharing the streams in one fork. 

Since I have no idea what Jan’s constraints are, I will not turn this into a programming 
lesson. I can say however, that what he wants to do is perfectly reasonable, and from 
his description of the problem it sure sounds like he found a bug in (gasp! Oh my gosh!) 
DECnet! 

By the way Jan, what version of TOPS-20 are you running? With respect to DECnet, 
there is quite a difference between version 6.1 and anything before that. If it’s 6.1, you 
would have a much better chance of getting your problem fixed. 

Stu Grossman 
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Date: Tue, 3 Mar 87 13:57:09 -0100 

From: enea!kuling!victor@seismo.CSS.GOV (Bjorn Victor) 

Subject: DECnet solutions? 

Hi fellows, 

We’re having some kind of problem here, I think. Let me explain our situation: 

Our site, ICU of Uppsala University, Sweden, is going to join the Swedish University 
Network (SUNET), which is built up with DECnet all over the country. We seem to have 
a couple of choices as to how to do it, and I’d like to hear your opinion. Any suggestions, 
or experiences of similar situations, are very welcome! 

SUNET is built in areas, with central routers for each area. The Uppsala area router 
is downtown, about 5km from our building. Our possible DECnet machines are our two 
2060s and a MicroVAX-II running Ultrix. Since the default ways of running DECnet on 
2060s is that you either run it on Ethernet (too short cables) or with a DN20, and since 
a Micro VAX can run it without a new FE, it seemed clever to attach the router to the 
Micro VAX, and have the 20s talk to the Micro VAX on Ethernet. 

Now, obviously, DECnet for Ultrix is only end-node, so it can’t route things for the 
20s. We don’t want to buy DN20s because they’re too expensive, so we seem to have two 
or three choices: 

1) Have the uVAX on SUNET, and have the 20s talk DECnet or TCP/IP with some 
amount of software on the uVAX to simulate routing for parts of the “application 
layer ’ (NFT, FTP, SMTP etc). If we were to choose this model and the TCP/IP 
case, we’cl be able to use SUNET from any machine in-house (since everybody talks 
TCP/IP). It would probably be very hard for people on SUNET to reach anything 
but the uVAX, though. 

2) Have the uVAX on SUNET, and basically only use it as a mail gateway as far as the 
20s are concerned. File transfers done by hand, logging in on Ultrix... 

or maybe... 

3) Have a 20 on SUNET through the normal FE, routing things for the other over 
DECnet on Ethernet. Is this possible? How poor performance would we get? Etc 
etc. 

Things that might be of importance: When we get our NIA-20s, we won’t be using 
the standard FE for terminals (more than one or two). Both DECnet-36, TCP/IP and 
NIA-20s are ordered for the 20s, but we still haven’t decided whether to get DECnet for 
Ultrix or not. It’s more important for us to get the 20s on SUNET than the uVAX (at 
least I think so). 

Any ideas? Please include me explicitly in replies, since my entry on the list (Vic- 
tor%A1DA.UPPSALA.SE@SEISMO.CSS.GOV) is off the “net” for yet another week or 
two. 

- Bjorn Victor 

Dept, of Computer Systems 

ICU, Uppsala University 

SWEDEN 


Date: Tue, 3 Mar 1987 16:07 EDT 

From: Mark H. Wood <IMHW400%INDYCMS.BITNET@wiscvm.wisc.edu> 

Subject: Routing off an Ethernet 

Regarding your mail to the TOPS-20 mailing list, which concerns your need to hook 
an Ethernet to SUNET: I’m not exactly a DECnet expert, but it seems to me that you 
have another option (if you have some money ). You can buy a DECSA-EA for just about 
half the cost of a DN20. The box will run synchronous lines at up to 500kb/s (with an 
add-in DCSAX-LA or -LB) and should do all the routing for your Ethernet. This is one 
of the primary functions of the DECSA, so support should be good; you may get no more 
than sympathy if you report problems with a DN20. Also, I think that the DN20 code 
is still at Phase III, so it may not be able to understand the network on the other side of 
your local area-router. 

I have no actual EXPERIENCE with a DECnet, but judging from the product bul¬ 
letins and catalogs, I would avoid both the DN20 approach (because of the area-routing) 
and the Micro VAX approach (because DECnet/Ultrix is end-node-only). Maybe some 
real experts can tell you how to make one of those methods work. I wish you good luck 
in any case. 


Date: Tue 3 Mar 87 17:33:52-EST 

From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU> 

Subject: Re: Routing off an Ethernet 

Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 

Phone: (212) 280-4876 

Re: DECSA Routers: 

The DECSA might not be long for this world either. Although it does currently run 
Phase IV DECnet (we run one here, currently configured to talk to up to 41 areas), and 
it seems to do its job fairly well (except when we get bad Ethernet jams, which we’ve 
been seeing lately for some other reasons), I’ve heard from various places that there’ll 
be some kind of VAX-based follow-on to replace it before long. So far all I have is some 
rumors and word of mouth stuff, so don’t take any of this as fact. However, the distinct 
^impression* I’m getting is that the DECSA will be another thing that will fade away. I 
can only hope that support for the DECSA will not evaporate as fast as TOPS-20 support 
seems to be. 

Anyway, there’s certainly no reason to pick up a DN20 at this point (other than that 
you can probably pick up used ones dirt cheap). Since DEC only went up to Phase III 
routing with them, unless you write your own code, it’s probably not worth it. Also, 
DECSA’s are a LOT smaller (we have ours sitting on top of one of our KL’s, instead of 
next to it taking up floor space). Except for some problems trying to run the DECSA 
fully configured for 63 areas and 1023 nodes per area, I’m very happy with it. /Ken 
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Date: Tue 3 Mar 87 17:51:29-EST 

From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU> 

Subject: Re: DECnet solutions? 

Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 
Phone: (212) 280-4876 

Forgot to mention about the DECSA before, there are only two DEC supported 
machines that can download this box: a VAX/VMS system and an RSX-11 system. 

We do neither, however. We download here from our TOPS-20 systems, and it seems 
to work just fine. The software gen process still has to take place on a VAX/VMS system, 
however. 

Anyone from DEC care to comment on how likely it will be that Ultrix will support 
DECSA’s (or whatever the follow-on VAX router will be)??? /Ken 


Date: Thu 5 Mar 87 00:47:42-PST 

From: David Roode <ROODE@BIONET-20.ARPA> 

Subject: file archiving 
Phone: (415) 962-7322 

I saw a message that talked about a primitive system of file archiving. We need on 
VMS what we enjoy on TOPS-20: an integrated file archiving and retrieval system. 

1. System manager can identify files not read or written in a specified period (i.e. dead- 
wood). Users can optionally be sent message listing such files. After potentially 
waiting for them to respond, the system manager can move the files to tape, leaving 
a pointer behind for the user, ONLINE. 

2. Users can have two quotas, working and permanent. Users over their permanent 
quota at a pre-defined time (2 a.m. MWF) are subject to forced migration of files to 
offline storage, with pointers left behind ONLINE. Users can identify files to leave on 
line at all costs, and specify the order for selection of files to move offiline. 

3. Users can selectively request archive of files in offline storage, with ONLINE POINT¬ 
ERS. A queue is maintained of files to be processed, with movement to offline status 
(ONLINE pointers) at a pre-defined time, i.e. 1AM MTWThF), as a part of normal 
system tape procedures, e.g. backup. 

4. Retrievals are requested at users’ convenience. An interactive command issued to 
review files currently in offline storage and to request retrieval of same. A queue is 
maintained, with files retrieved according to system policy, i.e. continuously during 
the day, within 1 hour, within 4 hours, daily at night, etc. 

5. All of this benefits from operational practice that once moved offline, 90% of files are 
never sought again by their owners. However, users are many times more amenable 
to removing data from online storage when online pointers and a retrieval path are 
maintained. Disk usage can be reduced by up to 50%, with minimal increase in 
operational overhead. And, DIGITAL HAS IT NOW, in TOPS-20, order number 
QT100. 


Date: Sun 8 Mar 87 14:40:41-PST 

From: William “Chops” Westfield <BILLW@Score.Stanford.EDU> 

Subject: bug in 6.1 apl4: re: incompletely created files... 

Our monitor, based on tops20 v6.1 apl4 or so, does not seem to properly get rid of 
“incompletely created files” when a fork is reset. Do other people have this bug, or is 
it suppsoed to be somehow considered a feature (related to CFS, I presume) We do not 
have a Cl, and we do not use CFS... 

Enjoy BillW 


Date: Sun 8 Mar 87 18:38:13-EST 

From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU> 

Subject: Re: bug in 6.1 apl4: re: incompletely created files... 

Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 
Phone: (212) 280-4876 

We have 6.1, a Cl, and CFS, and I believe we’ve seen that problem also in the past, 
although I was unable just now to recreate it. I even tried doing exactly what you did, 
Bill, and FTPed a chunk of SCORE’S monitor over here before fC-ing out (figured maybe 
it was just SCORE’S MONITR.EXE that was causing the whole problem :-), but couldn’t 
get it to break. I know I’ve seen this plenty of times before though. /Ken 


Received: by INDYCMS (Mailer X1.23b) id 0937: Wed, 11 Mar 87 08:11:08 EDT 
Date: Wed, 11 Mar 1987 07:59 EDT 

From: Mark H. Wood <IMHW400%INDYCMS.BITNET@wiscvm.wisc.edu> 

Subject: Re: bug in 6.1 AP14: incompletely created files 

I wonder if this is in any way related to my observation that ANY file, when deleted, 
may hang around for a few minutes before relinquishing its portion of one’s quota? Several 
of our users have complained that they have deleted a large file and found no immediate 
change in their quotas. The space always seems to be deallocated eventually. The file 
disappears from the directory immediately, but still takes up space. I suspect that this 
problem is related to OFN caching. Do the incompletely-created files EVER go away if 
you wait for a few minutes? 

Also, can anybody think of a good reason not to turn off OFN caching when the boot 
code determines that there is no KLIPA? For non-CFS sites (pronounced “most sites”), 
it looks like a waste of time and page frames. 


Date: Tue, 10 Mar 87 22:49:05-1000 

From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) 
Subject: Re: bug in 6.1 apl4: re: incomplete^ created files... 

We have encountered the incomplete file problem quite a bit lately. We have students 
writing programs which manage to consume their directory allocations and stop. A 
RESET does not free the allocated space and EXPUNGE, PURGE must be used. I 
called CSC and got the impression that they thought thats the way it was supposed to 
work. I plan to research and possibly SPR the problem soon ( a little side tracked lately). 
I might add that depending on the programming language (Pascal vs. FORTRAN), the 
problem may not occur. I suspect its related to the way OPENF is done. 
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We are running v6.1 apl4 (w/tcp). I believe the problem started after apl4. 

To reproduce the problem, I simply tried using a program like REV to copy a big file 
to a small directory. Sorry I can’t offer a solution, but I wanted to at least mention that 
we are having the same thing happening. 

-jeff- 


Date: Wed 11 Mar 87 11:00:22-PST 

From: Stu Grossman <GROSSMAN@Sierra.Stanford.EDU> 

Subject: Re: bug in 6.1 AP14: incompletely created files 

It sounds like the quota anomalies experienced by your users may be caused by the 
fact that they still have the files in question opened by some fork. They should try doing 
a RESET * followed by an EXPUNGE. It’s also possible that their file may be opened 
by someone else (in another job). If either of these cases is true, then you should be able 
to see the files in question as being deleted (the command DIR,<return>DEL will show 
them). 

Re: OFN cacheing, To clear the air a little (actually before it gets fogged up), OFN 
cacheing (conceptually) has nothing to do with CFS. Essentially, what it does is it keeps 
the monitor from flushing out all of it’s information about a file when nobody is currently 
accessing it. This means that the next reference to a file will be able to take advantage of 
the cached data. This is a big win for frequently accessed files. It also is (again concep¬ 
tually) independant of CFS. It interacts with CFS to the extent that OFNs are managed 
by CFS, and the consistency of the cached OFNs is maintained by CFS interlocking. 

To wit, my system does not have CFS, but when I put up AP14 I noticed an appre¬ 
ciable improvement in disk I/O bound stuff. 

The resource consumption due to OFN cacheing is pretty minimal. The OFNs get 
swapped out when nobody is using them. In addition, I think that there is a little extra 
table space (one or two words per OFN maybe?). 

Stu Grossman 


Date: Wed, 11 Mar 87 10:12 MST 

From: <RFORSTER@UNCAEDU.BITNET> 

Subject: Re: bug in 6.1 apl4: re: incompletely created files... 

We too have encountered the incomplete file problem here. Its almost a virus. Our 
environment is primarallv students. We found that our problems are directly related to 
the .TMP files created by COBOL (at apl4). The student will C out of COBOL and will 
find that all there space is used up. We go through the same ritual of RESET, CLOSE, 
EXPUNGE with PURGE to clear the problem. Its so bad here that I mailed the to 
procedure to the students just to keep them off my back. 

Until it was mentioned here, I thought we just had the problem so I put to student 
carelessness in their coding. 

/Russ 

Russell M Forster 


Date: Mon 23 Mar 87 16:41:20-EST 

From: Ittai Hershman <NYU.ITTAI@CU20B.COLUMBIA.EDU> 
Subject: Re: bug in 6.1 apl4: re: incompletely created files... 

A friend who has a TSC contract passed along the following patch: 
delfil+17/move a,.fbctl(d) 

for AP14 monitors. It is appearently fixed in AP15. I have not tested it... 
-Ittai 


Date: Mon 9 Mar 87 09:48:59-MST 

From: “Nelson H.F. Beebe” <Beebe@UTAH-SCIENCE.ARPA> 

Subject: Unix tar (tape archive) implementations on Tops-20 

A few years ago, Marshall Rose and John Romine at UC-Irvine wrote an implemen¬ 
tation of the Unix TAR (tape archive) utility in MACRO. I acquired a copy about 3 yr 
ago with our PCC-20 distribution, and have been intermittently adding features. It has 
now gotten to the point of being quite useful, with automatic byte size recognition and 
relative directory paths. In recent correspondence with John Romine, I obtained their 
most recent version, plus a copy of an independent one, also in MACRO, done by Chris 
Maio at Columbia in June 1983. 

At the top of my wishlist for future work is the conversion of this facility to C, to 
facilitate porting to other non-Unix systems. Neither the AT&T Unix TAR nor a public 
domain implementation posted on net.sources last fall seem to be suitable starting points, 
because (a) they lack the nice TOPS-20 COMND JSYS interface (for which I propose to 
use Kermit code), and (b) they know too much about Unix shells and directory structure. 

Since mjr version of the Rose/Romine TAR is now perfectly useful to me, a recoding 
and merging of features of the three MACRO versions is a lower-priority project which 
may or may not take place over the next several months, as time permits. The question 
I am posing here is, 

Has anyone else already done this, or developed yet another Tops-20 TAR, that they 
would be willing to share for the purposes of producing a version of wide utility and 
availability (I intend to support at least VAX VMS and IBM PC DOS, in addition to 
Tops-20)? 

Any modifications to either of the cited implementations would also be of interest. 

If a recoded version of TAR is prepared, I will certainly place it in the public domain. 
Presumably the GNU project will be producing a TAR too, but it may be closely tied to 
the underlying Unix operating system too. 
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Date: Mon 9 Mar 87 16:01:53-EST 

From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU> 

Subject: Re: Unix tar (tape archive) implementations on Tops-20 
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 
Phone: (212) 280-4876 

If you plan to COMNDize a C program, don’t use the existing Kermit code. You might 
want to use instead a more general interface written here at Columbia, called CCMD. I 
say “might” because it’s really still in beta test, although for the most part, it seems to 
be working fine. The CCMD distribution can be found on CU20B.COLUMBIA.EDU in 
WS:<SOURCE.CCMD>, and should be anonymously FTPable. /Iven 


Date: Thu 12 Mar 87 14:24:08-PST 

From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU> 

Subject: TOPS-20 MACSYMA 

Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 
Phone: +1 (415) 968-1052 

Jeff- 

I was forwarded a message from you regarding TOPS-20 MACSYMA, to the effect 
that “[Symbolics does’t] offer MACSYMA [for the DEC-20]. [Symbolics] stopped shipping 
DEC-20 MACSYMA at least a couple of years ago.” 

There are, however, a number of organizations with DEC-20’s that would like to get 
ahold of DEC-20 MACSYMA. 

Can I construe Symbolics’ position on DEC-20 MACSYMA to be one of abandon¬ 
ment, and that Symbolics is willing to forgo its proprietary rights on DEC-20 MACSYMA 
so that it may be placed in the public domain? 

Alternatively, if Symbolics continues to claim ownership of DEC-20 MACSYMA, will 
it be willing to grant various interested parties, such as myself, a no-fee licese to use and 
redistribute MACSYMA? 

If either is the case, I request a statement from Symbolics in writing so that everyone’s 
legal rights are protected. 

I propose, provided Symbolics permits it, to distribute DEC-20 MACSYMA as part 
of a general large volume of public-domain and semi- public-domain tools which I already 
distribute at very close to my cost. A MACSYMA distribution would probably be about 
$50, although if I have to deal with making people sign license agreements I’ll have to up 
the cost to $100 to cover my overhead. That is still quite within the cost of “freeware” 
and “shareware” distribution. 

My preference would be for Symbolics to get out of the DEC-20 business altogether 
and abandon its ownership of DEC-20 MACSYMA. This would be the best means to 
facilitate maximum possible distribution of MACSYMA. 

I am willing, as a concession to Symbolics’ commercial interests, to acknowledge your 
donation to our community in all associated documentation and to emphasize that more 
advanced versions of MACSYMA with larger capacity are avail;iLie for other CPU’s from 
Symbolics. The impact to Symbolics may end up being positive, as this would provide 
free advertising (consider how DEC-20 EM ACS provided the base for consumer demand 


for commercial versions of EMACS on other CPU’s). 

Thank you very much for you consideration. 
Regards, 

- Mark - 


Date: Sun 22 Mar 87 23:36:38-PST 

From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU> 

Subject: %Error reading HOME block on device 

If you get the subject message ever time you spin up a disk drive in the new monitor 
you’ve just built, it may be because the CHBHB1/CHBHB2 vector (200 words in all) 
is split across a page boundary. I don’t know if this happens on KL’s, but on 2020’s 
this seems to provoke the RH11 into getting a channel NXM. A possible fix is to move 
CHBHBl and CHBHB2’s definitions in STG.MAC to after the definition of CST5. 


Date: Mon 2 Mar 87 12:04:42-EST 
^From: Vince.Fuller@C.CS.CMU.EDU 
Subject: Daylight savings time 

A few months ago, it was mentioned that TOPS-20’s concept of Daylight Savings 
Time will need to be updated this year to agree with the latest Congressional decision. 
Has anyone written the code to check for year >1987 and apply the new rule? I’d like to 
know before I go and implement something myself... 

-Vince 


Date: Wed 18 Mar 87 16:26:42-CST 

From: Betsy Ramsey <G.Ramsey@R20.UTEXAS.EDU> 

Subject: Daylight Savings Time 
Organization: American Mathematical Society 

Apparantly there *is* a daylight savings time patch; it’s in the AP15 monitor. Here’s 
the extract from the T26V61.D15 file: 

EDIT 7388 FOR MONITOR V6.1 

[SYMPTOM] 

New law states that daylight savings time in 1987 will start on the first Sunday in 
April as to the current law of last Sunday in April. 

[DIAGNOSIS] 

Currently, daylight savings time starts in last Sunday in April and there is no code 
to implement the new law. 

[CURE] 

Add code in routine NLSS to check whether the new or the old law applies (base on 
the year) and return the first or last Sunday in April as the day DST is to be started. 
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(Does anyone know if this patch lias been published? I couldn’t find it in a quick 
skim of the dispatches. ) 

For non-source sites running pre-AP15 monitors, TSC provided the following patch: 

In module DATIME, change the contents of location DSTON from 167 octal to 141 
octal. 

Here’s a photo of this patch using my API3 monitor: 

©ENABLE 

$GET SYSTEM:MONITR.EXE 

$ START 140 

DDT 

datime$: 

dston/ INCODL+2 =167 141 

TZ 

$SAVE SYSTEM:NEW-MONITR.EXE 
<SYSTEM>NEW-MONITR.EXE.l Saved 
$DISABLE 

I have not actually applied or tested this patch. 


Date: Wed, 18 Mar 87 16:51:02 CST 
From: Billy Brown <Billy©Mcc.Com> 
Subject: Re: Daylight Savings Time 


We’re using the following patch (5.4 monitor) that works... 


NLSS: 


MOVE E,BB 
SUB E,D 
ADD E,DSTON 
HLRZ F,B 
CAIL F, |D1987 
SUBI E,|D23 
ADDI E,DWFUDG+|D701 


DATE TODAY 

-DAY OF YEAR TODAY = BEG OF YEAR 
LAST POSSIBLE DAY FOR DST START 
[*] GET YEAR 
[*] 1987 OF AFTER? 

[*] YES, USE FIRST SUNDAY INSTEAD OF LAST 
+1 TO MAKE SUNDAY, NOT MONDAY, =0. 


[The difference between this patch and the previous one is that this one will preserve 
accurate date/times for files created in early April of previous years. -CD] 


Date: Sun 22 Mar 87 15:46:36-PST 

From: Mark Crispin <MRC%PANDA©SUMEX-AIM.Stanford.EDU> 

Subject: latest and greatest summer time patch! 

To: TOPS-20©Score.Stanforcl.EDU 

Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 
Phone: +1 (415) 968-1052 

Here is the fix I use for the new law. Note that all you have to do when Congress 
plays around again is make an addition to the RULES macro. 

This patch accounts for the two “war times” during WWI and WWII and also fixes 
a bug in NLSS where F (the index into the rules) was clobbered by an IDIVI. So install 
this patch instead of the one I sent earlier. Note that the second edit is installed in two 
places in the code, one for IDTIM and one for ODTIM. 


Enjoy! - Mark - 

***** DATIME.DEC 
sDSTBGN::|D1975 

DSTON:: |D<31+29+31+30>-l ;LAST SUNDAY IN APRIL 
DST0FF:1D<31+29+31+30+31+30+31+31+30+31>-l 

;LAST SUNDAY IN OCTOBER 

***** DATIME.MAC 

;;; This represents an attempt to make it easier to change the 
;;; summer time rules to reflect the latest games Congress chooses 
;;; to play with when summer time starts and ends. In theory, you 
;;; should be able to make an appropriate addition to the RULES 
;;; macro. Of course, if your country doesn’t play along by US law, 

;;; you will have to make some additional modifications. 

;;; Note that VAX/VMS doesn’t have any algorithm for summer time! 

RADIX <5+5> ;DECIMAL RADIX 

;;; First and last Sundays of certain useful months 
FSTJAN==7-1 ;FIRST SUNDAY IN JANUARY 
LSTFEB==31+29-1 ;LAST SUNDAY IN FEBRUARY 
LSTMAR==31+29+31-1 ;LAST SUNDAY IN MARCH 
FSTAPR==31+29+31+7-1 ;FIRST SUNDAY IN APRIL 
LSTAPR==31+29+31+30-1 ;LAST SUNDAY IN APRIL 

LSTSEP==31+29+31+30+31+30+31+31+30-1 ;LAST SUNDAY IN SEPTEMBER 
LST0CT==31+29+31+30+31+30+31+31+30+31-1 ;LAST SUNDAY IN OCTOBER 
DEFINE RULES < 

DST 1987,FSTAPR,LST0CT ;; Changed again 

DST 1976,LSTAPR,LST0CT ;; Energy conservation legislation expired 
;; Note: contrary to what some people (and certain operating systems) 

;; believe there was not year-round DST in 1974. At the last minute 
;; Congress restored the end-of-October restoration of standard time. 

DST 1975,LSTFEB,LST0CT ;; Rule changed in October 1974 
DST 1974,FSTJAN,LST0CT ;; Energy conservation emergency 
DST 1967,LSTAPR,LST0CT ;; Congress established national standard 
;;; Prior to 1967 there was no uniform application of DST in the USA, 

;;; although many areas used the "last Sunday in April until last Sunday 
;;; in October’’ rule. These entries cannot be taken seriously. 

assumes you had DST 
this would probably be better 
WWII "War Time’’ ended Sunday 30 Sep 45 
WWII "War Time” was all year 1943-1944 
WWII "War Time” started Monday 9 Feb 42 
no real standard existed 
temporary summer time during WWI 

<YEAR> 

<START> 

<END> 

UJlUi'I' . . ibU LiLjJ 

NRULES==.-DST0FF 
IFE NRULES,<PASS2 


DST 1946,LSTAPR,LST0CT ;; 
; DST 1946,400,400 ;; 

DST 1945,0,LSTSEP 
DST 1943,0,400 ;; 

DST 1942,31+9,400 ;; 

DST 1920,400,400 ;; 

DST 1918,LSTMAR,LST0CT ;; 

>;DEFINE RULES 

DEFINE DST(YEAR,START,END) 
DSTBGN:: RULES 

DEFINE DST(YEAR,START,END) 
DSTON:: RULES 

DEFINE DST(YEAR,START,END) 
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PRINTX ?THERE MUST BE AT LEAST ONE DST RULE 
END> ;SANITY CHECK 

RADIX <4+4> ;BACK TO OCTAL 


***** Note! ! This change is installed in TWO places in the code ***** 
***** DATIME.DEC 

CAMGE E,DSTBGN ;AFTER CURRENT LAW WENT INTO EFFECT? 

JRST 0DAY9 ;N0, NO DST 


CAMGE E,DSTBGN ;AFTER CUJ 

JRST 0DAY9 ;N0, NO D! 

***** DATIME.MAC 

MOVSI F,-NRULES ;INDEX IN' 

DO. 

CAML E,DSTBGN(F) ;IS THIS : 

EXIT. ;YES, USE 

AOBJN F,T0P. ;TRY NEXT 

JRST 0DAY9 ;NO SUMME 

ENDDO. 

***** Remember!! Install this twice ***** 


INDEX INTO RULES TABLE 

IS THIS RULE VALID FOR THIS YEAR? 
YES, USE IT FOR SUMMER TIME 
TRY NEXT RULE 
NO SUMMER TIME 


***** DATIME.DEC 
NLSS: MOVE E,BB 

SUB E,D 
ADD E,DSTON 
ADDI E,DWFUDG+|D701 


IDIVI E,7 
IMULI E,7 

SUBI E,DWFUDG+|D701 


DATE TODAY 

-DAY OF YEAR TODAY = BEG OF YEAR 
LAST POSSIBLE DAY FOR DST START 
+1 TO MAKE SUNDAY, NOT MONDAY, =0. 

700 IS ARBITRARY MULTIPLE OF 7 TO MAKE SURE 
QUANTITY IS POSITIVE DURING DIVISION EVEN 
IN 1858, WHEN NLSAPR AND NLSOCT ARE NEGATIVE. 
DIVIDE INTO WEEKS AND DAY OF WEEKS 
CONVERT BACK, DISCARDING DAY OF WEEK 
UNFUDGE AND WE'VE GOT IT! 


;DATE OF LAST SUNDAY IN OCTOBER (NLSOCT) THIS YEAR TO F. 


MOVE F,BB 
SUB F,D 

ADD F,DSTOFF ;LAST POSSIBLE DAY FOR DST END 

ADDI F,DWFUDG+fD701 
IDIVI F,7 
IMULI F,7 

SUBI F,DWFUDG+|D701 
RET 

***** DATIME.MAC 
NLSS: MOVE E,BB 

SUB E,D 
ADD E,DSTON(F) 

CALL NLEAP 
SKIPA 
SUBI E,1 

PUSH P,DSTOFF(F) 

MOVE F,DSTBGN(F) 

CAIE F, |D1942 
IFSKP. 

ADDI E,DWFUDG+|D700 ;S0 DON'T ADJUST FOR SUNDAY FOR THIS YEAR! 
IDIVI E,7 
IMULI E,7 

SUBI E,DWFUDG+ j D700 


-DAY OF YEAR TODAY = BEG OF YEAR 
LAST POSSIBLE DAY FOR DST START 
IS IT A LEAP YEAR? 

YES 

NO, CAN'T BE SUNDAY, MAY 1! 

SAVE RETURN TIME 
GET YEAR 

WAR TIME STARTED ON A MONDAY 
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ELSE. 

ADDI E,DWFUDG+|D701 ;+l TO MAKE SUNDAY, NOT MONDAY, =0. 

;700 IS ARBITRARY MULTIPLE OF 7 TO MAKE SURE 
;QUANTITY IS POSITIVE DURING DIVISION EVEN 
;IN 1858, WHEN NLSAPR AND NLSOCT ARE NEGATIVE 
IDIVI E,7 ;DIVIDE INTO WEEKS AND DAY OF WEEKS 

IMULI E,7 ;CONVERT BACK, DISCARDING DAY OF WEEK 

SUBI E,DWFUDG+|D701 ;UNFUDGE AND WE'VE GOT IT! 

ENDIF. 

OF LAST SUNDAY IN OCTOBER (NLSOCT) THIS YEAR TO F. 

POP P,F ;LAST POSSIBLE DAY FOR DST END 

ADD F,BB 
SUB F,D 

CALL NLEAP ;IS IT A LEAP YEAR? 

SKIPA ;YES 

SUBI F,1 ;NO, CAN'T BE SUNDAY, NOVEMBER 1! 

ADDI F,DWFUDG+|D701 
IDIVI F,7 
IMULI F,7 

SUBI F,DWFUDG+|D701 
RET 
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The information in this document is subject to change 
without notice and should not be construed as a 
commitment by Digital Equipment Corporation. Digital 
Equipment Corporation assumes no responsibility for any 
errors that may appear in this document. 
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The Next Release of DECnet/E 


History 


o Phase 1 - Didn't exist on RSTS 
(thank goodness) 

o Phase 2 - Can only talk to neighbors 
VI.0 - RSTS V6C 
VI.1 - RSTS V7.0 

o Phase 3 - Can talk to anyone in network 
V2.0 - RSTS V7.1 
V2.1 - RSTS V9.0 

o Phase 4 - Larger easier to manage networks 
V4.0 - RSTS V9.3 

Note: There is NO V3 of DECnet/E. We are skipping it to 
avoid any further version/phase confusion. 


V4.0 Features 

o Ethernet support 

o Larger networks 
63 areas 

1023 nodes per area 

o Higher speeds 

Ethernet - 10 Mbits/second 


What is Ethernet? 

o High speed communications link 

- 10 Megabits/second 

o Local area network 

- within 2.8 Kilometers 
o Shared wire 

- 1023 nodes per ethernet wire 

- Results in lower cost interconnect 


The Phase IV Network 

o Phase 3 limits to 255 nodes in the network 

o Phase 4 limits increased 

- 1023 nodes per area 

- 63 areas 

o Using more than 1 area requires a non-RSTS system 

- VAX/VMS 

- RSX 

- DECSA 
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Using DECnet/E V4.0 


o Can be an End Node 

- Saves memory 

- Saves CPU cycles 

o Can be a Level 1 router 

- Uses more memory 

- Uses more CPU cycles 

- Route to anyone within same area 

- Can access other areas using a Level 2 router 

o Level 2 router 

- Routes between areas 

- Can not be the RSTS system, must be 
VAX/VMS, RSX, or DECSA 

Installation 

o Removed from SYSGEN 

o Installation is the same as any standard RSTS/E 
layered product 

o Can be added at ANY time 

o Does not require re-SYSGEN 
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SYSGEN 


o DECnet/E question removed 
o No DEUNA/DELUA device questions 
o No DEQNA device questions 

o Drivers included in all monitor disk images 

o Only loaded into memory if DECnet 
is installed and hardware is present 

o DMC/DMR/DMP questions still present 

Performance 

o Ethernet provides a high speed communication channel 

- SET HOST looks more like a local terminal 

o Reduced buffer handling within the monitor 

- Performance is improved 

o NFT/FAL performance improved. 

- Flow control is no longer required. 

Restrictions (at least for this release) 

o NO Level 2 (Area) Routing 

- Must have a non-RSTS system to route between 
areas 

o NO LAT support 

- Terminal servers will not be supported 
in this release 

o NO non-DECnet access to Ethernet 

- Non-DECnet access will not be supported 
in this release 
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Supporting 


October 6-10 



1986 Fall DEOUS 

San Francisco 


The information in this document is subject to change 
"Large" Disks on RSTS without notice and should not be construed as a 

commitment by Digital Equipment Corporation. Digital 
Equipment Corporation assumes no responsibility for any 
Dave Freund errors that may appear in this document. 

RSTS Development. 
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PACK LABEL 


OFFSET 


0 or 1 I 0 

-1 I 2 

DCN Of MFD | 4 

Disk Version Number j 6 

PCS | 10 

Status | 12 

PACK-ID | 14 

-1 

IN RAD-50 16 


Reserved j 

for future j 

Pack | 

Attributes j 

- 776 


BLOCK 1 of RDS1 DISKS 

PACK STATUS WORD 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


1 

1 

1 1 1 

1 1 \ 


/ 

1 

1 

j 

1 

1 

I 

1 1 ! 

1 1 ! 

i 

i i 

i I 

l 

V 

RESERVED 


1 

1 

1 

1 

i 

1 1 1 

1 1 1 

i i i 

1 1 

j \— NFF 

l 



1 

1 

1 

1 

1 

i 

l l l 

1 1 ! 

i i i 

1 

\— RESERVED 



1 

1 

1 

1 

1 

l 1 1 

1 1 \— 

i i 

DLW 



1 

1 

1 

1 

1 

i 

1 l 

| \— READ 

i 

ONLY PACK 



1 

1 

1 

1 

1 

i 

1 

\— RDS1 PACK 




1 

I 

1 

1 

\— 

PRIVATE/SYSTEM 





\— MOUNTED 
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RDSl MFD 



1 

1 

Reserved Blockettes 

1 

1 

Block 

o 1 

for 

1 


1 

future Group/Pack 

1 


i 

i 

Attributes 

i 


1 

1 

1 WORD/GROUP 

1 

1 

Block 

1 | 

1 

1 

1 

DCN of GFD 

1 

1 

1 

1 


1 

1 

1 WORD/GROUP 

1 

1 

Block 

2 1 

Group ATTRIBUTE 

1 


1 

POINTER 

1 


1 

1 

i 

(RESERVED) 

1 

1 

Block 

1 

1 

1 

Reserved Blockettes 

1 

1 

3 to 

/ 

for 

/ 

end 

/ 

Future Group/Pack 

/ 


1 

1 

Attributes 

1 

1 


MFD CLUSTERSIZE - 4,8,16 


BLOCK 0 IN THE MFD 


0 


-1 


0 


0 


0 


Pack Attribute Pointer 


255. | 255. 


'MFD' in RAD-50 


| reserved j 

/ for blockettes / 

/ / 


1 | Clustersize 


DCN 0 of MFD 


DCN 1 Of MFD 


DCN 2 Of MFD 


DCN 3 of MFD 


DCN 4 Of MFD 


DCN 5 Of MFD 


DCN 6 Of MFD 


BLOCK 1 IN THE MFD 


OFFSET 


OFFSET 

0 

2 

4 


| DCN for Group 0 GFD | 

1 DCN for Group 1 GFD j 

DCN for Group 2 GFD | 
j DCN for Group 3 GFD j 


j DCN for Group 253 GFD j 
| DCN for Group 254 GFD | 


6 

Contains the DCN for each 
10 group file directory that 

12 exists. If 0, then that 

group does not exist. 

14 


16 


RDSl GFD 


0 

2 

4 

6 

772 

774 

776 


760 

762 

764 

766 

770 

772 

774 

776 


i i 

| Blockettes for | 

j UFD Name/Accounting/ ] 

| Attribute Entries j 

i i 

i i 

i 

i 

i 

1 WORD/USER 

i 

i 

i 

DCN of the UFD 


i 

1 WORD/USER 


i 

i 

i 

Name Blockette Pointer 


I 

i 

Blockettes for 

i 

/ 

UFD Name/Accounting/ 

/ 

/ 

i 

Attribute Entries 

/ 

i 


Clustersize of GFD - 
BLOCK 0 


BLOCK 1 


BLOCK 2 


BLOCK 3-END 


,8,16 
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BLOCK 1 IN THE GFD 


BLOCK 0 IN THE GFD 

OFFSET 
0 
2 
4 
6 

10 
12 
14 
16 


760 

762 

764 

766 

770 

772 

774 

776 


0 


-1 


0 


0 


0 


0 


Group # | 255. 


'GFD' IN RAD-50 


j Reserved 

/ for blockettes 

/ 


1 | Clustersize 


DCN 0 of GFD 


DCN 1 of GFD 


DCN 2 Of GFD 


DCN 3 of GFD 


DCN 4 of GFD 


DCN 5 Of GFD 


DCN 6 Of GFD 


OFFSET 


1 

1 _ 

DCN 

for 

User 

0 

UFD 

1 

0 

1 

1 

1 _ 

DCN 

for 

User 

1 

UFD 

. 

1 

1 

. | 

2 

1 

1 _ 

DCN 

for 

User 

2 

UFD 

1 

1 

4 

1 

1 

1 _ 

DCN 

for 

User 

3 

UFD 

" 1 

. | 

6 

I 

/ 




. 



1 

/ 


/ 

1 _ 




• 



/ 

_ 1 

• 

1 

1 

DCN 

for User 

253 

UFD 

1 

1 

. | 

772 

_ 

1 

1 _ 

DCN 

for User 

254 

UFD 

I 

1 

. | 

774 

1 

1 




0 



1 

1 

776 


BLOCK 2 IN THE GFD 

OFFSET 


i 

i 

1 _ 

Name blockette 
pointer for User 

0 

1 

1 

0 

1 

1 

1 

j _ 

Name blockette 
pointer for User 

1 

_ 

1 

1 

1 

_ i 

2 

1 

1 

1 

1 _ 

Name blockette 
pointer for User 

2 

1 

1 

1 

_ | 

4 

1 

i 

i 

1 _ 

Name blockette 
pointer for User 

3 

1 

1 

1 

_ | 

6 

1 

/ 

# 


1 

/ 

# 

/ 

1 _ 

• 


/ 

_ | 

• 

1 

1 

1 

1 _ 

Name blockette 
pointer for User 

0 

1 

1 

_ | 

772 

1 

1 

1 

i _ 

Name blockette 
pointer for User 

0 

1 

1 

_ | 

774 

1 

1 

0 


1 

1 

776 


Contains the DCN for each 
user file directory in this 
group. If 0, then that user 
does not have a UFD. That 
account may still exist however. 


Contains the Name blockette 
pointer for each User in this 
group. If 0, then that account 
does not exist. 
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BLOCK 3 TO END of THE GFD 

OFFSET 


| 8 Word Blockette | 0 

| - , 

j 8 Word Blockette | 20 

, - | 

| 8 Word Blockette | 40 

i-1 

/ / 

/ / 

i-1 

j 8 Word Blockette j 740 

|- 1 

j 1 | Clustersize | 760 

|-1 

j DCN 0 of GFD j 762 

| - | 

| DCN 1 of GFD j 764 

| - | 

I DCN 2 of GFD | 766 

j DCN 3 of GFD | 770 

| - | 

| DCN 4 of GFD j 772 

| - | 

j DCN 5 of GFD | 774 

| - | 

I DCN 6 of GFD | 776 
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MFD/GFD Name Blockette 


MFD/GFD Accounting Blockette 




OFFSET 


Attribute Pointer | 

_ i 

0 

| 1 

l.. _ . .... . 

Group # | 

User # | 

.. _ _. i 

2 

1 

| CPU Time (LSB) 

i 

(password 

1 

RDS0) 0 1 

4 

1 — 

| Connect Time 

(password 

" 1 

RDS0) 0 j 

. i 

6 

i KCT'S (LSB) 

1 - 

Prot | 

1 

Status | 

... . . . i 

10 

1 - 

| Device Time 

i 

Access 

1 

Counts | 

i 

12 

1 

j CPU & KCT'S (MSB) 

1 .. . 

i 

Accounting Pointer | 

i 

14 

1 - — ' ^ ~ 

| Logged Out Quota 

1 . 

DCN of 

i 

UFD | 

16 

1 

| UFD Clustersize 


DCN MUST agree with block 1 of GFD 


GFD ATTRIBUTE BLOCKETTE 


0 Type 1 = Disk quota 

Type 2 - Privilege 
2 Type 3 - Password 

Type 4 - Account date/time 
Type 5 * Account name 
. Type 6 * Quota part 2 

Type 7-199 = Reserved for DEC 
. Type 200-255 - 

Reserved for Customers 


16 


Pointer to next 
I TYPE 


attribute 

data 
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Quota Attribute Blockette 


Privilege Attribute Blockette 


| pointer to next 
| Det Job QT | 1. 

j Logged out (LSB) 

| Logged in (LSB) 

| L out MSB | L in MSB 
|Usage MSB | Reserved 
Reserved 


j Current Usage (LSB) 


Password Attribute Blockette 


pointer to next 
I 3. 


Password 

Data 

Ascii or Hashed 


pointer to next 
Reserved | 2. 

Authorized Mask 
(4 words) 


Reserved 

Reserved 


DATE/TIME Attribute Blockette 
| pointer to next | 

i-1 

| Last KB # I 4. j 

I-1 

| Date of last login j 

|-1 

| Time of last login | 

|-1 

| Date last pass change | 

|-1 

| Time last pass change | 

| - , 

| Date of creation | 

| - | 

| Expiration date (1.2) | 

j Creation time (1.1) j 
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Extra 

Hidden Information 

| | | | | | Last login time | 

\ 


/ i 


i 

1 

\-> No password required 



-> Reserved 

| | | | | | Password change time | 


| j j | \-> Password not readable (its hashed) 

I I I I 

| | I \-> No dialups allowed 

i i i 

| j \-> No Network allowed 

I I 

| \-> No Interactive Logins 

I 

\-> Captive account 


Name 

Attribute 

Blockette 

Quota 2 Attribute Blockette 

i 

pointer to 

next | 

| pointer to next 

i 

i 

i 

i 

--1 

5. | 

i 

j Tot job Qt | 6. 

i __ _ 

i 

i 

i 


1 

1 

i 

1 

| Receiver ID Block Qt 

i „ „ 

I 

1 

i 

i 

User 

1 

1 

i 

1 

| Message limit Quota 

i 

i 

i 

i 

i 

Name 

1 

1 

i 

1 

1 

I 

1 

1 

i 

i 

(Ascii) 

1 

1 

1 

1 Reserved 

i 

1 

i 

i 
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Block 0 in the UFD 


Block 1 to end of UFD 


OFFSET 


- 

Link to First File 

-1 

i 

1 

2 

0 

i 

i 

i 

8 Word Blockette 

1 

1 


0 

I 

4 

20 

i 


1 

- 





1 

8 Word Blockette 

| 


0 

i 

6 


i 


1 


0 

i 

10 


i 


1 

I 


0 

i 

12 


1 

1 


1 

| 

- 





/ 


/ 


Group # | User # 

i 

14 


/ 

1 


/ 

1 


'UFD' in RAD-50 

1 

16 


1 

i 


1 

1 


Reserved 

i 


740 

i 


1 

/ 

for blockettes 

/ 

. 


i 

8 Word Blockette 

1 

/ 


/ 

• 


i 


1 


Clustersize 

i 


760 

i 

Clustersize 

1 

1 

DCN 0 of UFD 

1 


762 

I 

DCN 0 of UFD 

1 

1 

DCN 1 of UFD 



764 

I 

DCN 1 Of UFD 

I 

1 

DCN 2 of UFD 

1 


766 

i 

DCN 2 of UFD 

1 


DCN 3 of UFD 

i 


770 

i 

DCN 3 of UFD 

1 

1 

DCN 4 of UFD 

i 


772 

i 

DCN 4 of UFD 

1 

1 

DCN 5 Of UFD 

i 


774 

1 

DCN 5 of UFD 

1 

1 

DCN 6 Of UFD 

i 


776 

! 

DCN 6 of UFD 

1 
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UFD Name blockette UFD Accounting blockette 

OFFSET 
0 
2 
4 
6 

10 
12 
14 
16 


Status Byte 


j j | j j j j \—> (Historical) 

i i i i i i i 

j | | j j j \-> File is placed 

I I I I I I 

j j I j | \-> (Historical) 

I I I I I 

|j|| \-> (Historical) 

I I I I 

| | | \-> Contiguous 

I I I 

| | \-> No Delete/Rename 

I I 

j \-> MFD type entry (RDSO only) 

\-> Marked for delete 


Next file pointer 
File name 


in (RAD50) 


File type (RAD50) 
Prot | Status 
Access counts 


Accounting pointer 
Retrieval pointer 


Link to attributes 


DLA or DLW 


File Size (LSB) 


Creation Date 


Creation Time 


RTS pt 1 or 0 
RTS pt 2 or size (MSB) 
File Clustersize 
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File attribute Entry 


Protection Code Byte 


I I I 


I I I 


V 


V 


\—> No Owner read (execute if 64 set) 


j j j j \-> No Owner write (R/W if 64 set) 

I I I I 

j | j \-> No Group read (execute if 64 set) 

i i i 

j j \-> No Group write (R/W if 64 set) 

I I 

| \-> no World read (execute if 64 set) 

I 

\-> No World write (R/W if 64 set) 

-> Executable File 

-> Erase, Prived if executable 


Retrieval Entry 
Link to Next Retrieval 


DCN of file data 
7 DCN's (end-0) 


Link to attribute entry 2 or 0 
Organization 
Record Size 


(MSB) 

Highest Block # in file 
(MSB) 

EOF Block # 

First Free byte in EOF Block 


Organization Word 


i 


i 


\ 


i 

i 

Print Control 

1 - Fortran 

2 - <CR> 


/ \ / \ 
I 
I 

Organization 
0 - Sequential 

1 - Relative 

2 - Indexed 


Format 

0 * Undefined 

1 - Fixed 

2 - Variable 

3 - VFC 

4 - Stream 


4 - Unused 

10- No Span Blocks 


File attribute Entry part 2 

0 Link 
Bucket Size 

Max Record Len encountered 


Reserved 
(5 words) 
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Flag Bits 


\-> Entry in use (offset 0 link word) 


1 I \-> Bad block in file (Name entry blockette) 

I I 

| \-> Cache file (name blockette) 

j Sequential cache (Accounting pointer) 

\-> Clean Bit (used by clean, normally 0) 


RST-24 






















The RSX Mu Iti-Tasker 
May, 1987 


"Semper Drunk" 

Fine Realtime Commentary Since 1975 
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Opinions expressed in the editorial section of the 
Multi-Tasker are those of the Editor. They do not 
represent the official position of the RSX SIG or that 
of DECUS leadership in general. 


Food for Thought 


"The fears of man are many. He fears the shadow of death and 
the closed doors of the future. He is afraid for his friends and for 
his sons and of the specter of tomorrow. All his life's journey he 
walks in the lonely corridors of his controlled fears, if he is a 
man. For only fools will strut, and only cowards dare cringe." 

- James Warner Bellah 
Spanish Man’s Grave 


The Editor’s Corner 

Bruce R. MitcheI I 


This issue is hitting the streets just about the time that the 
Spring Symposium is ending. As we go to press, I'm sure there will 
be many interesting, exciting and significant things happening at 
Nashville. Recantation of those things would be timely in this 
issue. 

Unfortunately, it's late March now, and I seem to have misplaced 
my crystal ball. The earliest articles from the Spring Symposium 
will be in the July issue. 

V\fe have a wunnerful, wunnerful selection of articles this month. 
The European contingent weighs in strong with two articles. Way to 
go, guys! Keep up the good work. 

For those readers intrigued with last month's mention of the 
ODS-2 ACP, we're publishing a support article for reference when the 
ACP is released. The ODS-2 FiIes-11 On-Disk Structure , less the 
file-specific sections, rounds out this month's issue. 
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Send more articles; there are still about 30 of the prints of 
the Fall 1986 SIG button artwork to give away. These prints are a 
limited edition, all signed by the artist and certified. The only 
way you can get one is to contribute an article. And, as always, if 
you don't want to write an article, at least drop a line telling what 
kind of articles you'd like to see in the Multi-Tasker. 

Turn the Editor's crank, get an editorial. The Editor's crank 
was turned quite well this month. So were a few others. 


Cheap Wi ne 


"The Multi-Tasker Editor has eaten sour grapes, 
and the users' teeth are set on edge." 


I am so angry I could just spit tacks. 

Something stinks within DECUS. And generally, when something 
stinks, it's a sign that the odoriferous something is decaying; 
sometimes, decaying from within. 

By the time you read this issue, the elections for the Board of 
Directors will be accomp lished. Therefore, I can continue wi th the 
editorial started last month without fear of "electioneering" 
accusations. 

There probably will be other accusations leveled at me after 
this hits, but let the chips fall where they may. We 're not proud. 

I stated in last month's issue that The Multi-Tasker had to 
remain neutral on the election. I don't know if this is official 
graven policy; this is what I was told. But why should an official 
SIG organ not support candidates who are favorable to the aims of 
that SIG? 

I also implied that an unnamed entity may have tried to - hnrm, 
how shall I put this - "influence" the election. That entity is 
LDEC, the Leadership Development and Election Conrmittee. It is 
charged with running fair elections, among other things. 

The flyer accompanying the ballot just crossed my desk several 
days ago. I am still having somewhat of a difficult time seeing 
straight. 

There appears to have been another attempt to influence the 
vote. I mean the references to candidates as "Slated by the 
Leadership Development and Elections Committee'' or "Slated by 
petition". This is very bad just by itself, but apparently it wasn't 
sufficient to put it out on the front page in bold print; it was 
also tagged to the bottom of each candidate's statement. 


If this isn't electioneering by making certain candidates appear 
"blessed and approved". I'll eat my 11/60. 

I have done some investigation into this. I have chatted with 
some of the candidates "slated by petition". Their qualifications 
appear very good to outstanding. But in one particularly grating 
case, a candidate who received a national leadership award from LDEC 
was told, when interviewed by LDEC, those qua I ifications weren't good 
enough to run for Board. 

It is surely only a coincidence that some candidates forced to 
petition appear to wish to change the direction of the Society. It 
doesn't matter whether that viewpoint is "right" or "wrong"; DECUS 
is a democratic organization. In such an organization it cannot be 
wrong to seek to return control to the members. But it sure looks to 
me as though someone thinks it is. 

Something stinks within DECUS. I hope it's not too late to cut 
out the rot. 


- Submitting Articles to the Multi-Tasker - 

Please submit machine readable media if you can. RX01, RX02, 
RX50, or 9 channel magtape at 800 or 1600 BP I are best. Any RSX 
volume format is acceptable except ROLL IN or PRESRV. ANSI, BRU and 
DOS FLX formats are we 1 I — I iked by the Editor's tape drive. 

The Editor can now Kermi t articles out of other hosts into the 

Multi-Tasker host. The reverse is unfortunately not true; the 

MuIti-Tasker host is norma lly an isolate. If you want to submit an 
article via Kermit, call beforehand with (1) phone number, (2) login 
for the host machine and (3) system uptimes. 

Submissions which aren't machine readable take longer to get 

into print. The editor is lazy and types mass quantities only once a 
month when progress reports are due. 

If you preformat a submission in RUNOFF format, please set page 
size 58,80; left margin 10; right margin 75; and, when changing 
margins, use incremental changes rather than absolute. The editor 
blesses you for the consideration. 

Send all submissions to: 

Bruce R. MitcheI I 

Machine Intelligence and Industrial Magic 
PO Box 816 
Byron, MN 55920 
(507) 775-6268 
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- And That's The Way Things Are - 

... this month in Poo I Lowbegone, where the PDP-11 is still 
going strong, the new doc sets are good-looking, and the tendency of 
the newsletter editor to flame is above average. 


Creative RSX Executive Patching 

James A. McGlinchey 
Software Engineering Consultant 
Post Office Box 81 
Essex Junction, VT 05452-0081 
(802) 879-6014 


RSX has been carefully coded so that many of its SYSgen 
parameters end up being constants, and all those constants are 
collected and put into the Exec's SYSCM module. SYSCM contains such 
iterns as: 

$TKPS The line frequency, typically 60 
SSYSNM The system's name (DECNET Node Name) 

$COMEF The global event flags (EFNs 33.-64.) 

SCKLDC KW11-P clock countdown 

SSYUIC The system UIC (typically [1,54]) 

SFMASK Table of system features, shown as bits 
SDYPMN Days-per-month table 

$BTMSK Table of bit masks 

$PKMAX Maximum number of pre-aI I ocated I/O packets 
SPRIHL POOL monitor task control parameters 
SPFRSZ 
$POLBP 

A lot of RSX tweaking and tuning can be done by changing various 
constants in the Exec and its data areas. Admittedly, many of these 
items can be changed via MCR or DCL commands, but some can be changed 
only with a new SYSgen. 

I hate doing SYSgens. I'd rather apply a patch to RSX to change 
something that would ordinarily require a SYSGEN. For this reason, I 
use pregenerated RSX distribution kits for normal RSX systems (if 
there be such a thing), and often must change something in the Exec. 

I prefer to make changes to the Executive after all the 
bootstrap dust has settled. I apply patches with a program run from 
STARTUP.CMD rather than ZAPping the Executive. Other wizards might 
argue that ZAP is better for such things, but I find ZAPping the Exec 
to be troublesome for several reasons: 
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Mistakes made with ZAP can be tragic, as the change is permanent. 

Changes made via ZAP are not documented, and therefore are not 
guaranteed to be reproducible. 

I can't remember how to run ZAP. I have to learn it every time I 
use it. So I try not to use it. 

My preferred technique is a patcher program, a listing of which 
is shown below. The program switches to kernel state via the SMSTKS 
macro, applies the changes, and then exits. I prefer this because it 
is reproducible and easily ported from system to system. 

The example shown below applies a six character patch to change 
the system name. The code inserted between the ^ASTKS line and the 
RETURN line actually does the patching, and this is the only code the 
user would change to apply other patches. The rest is boilerplate 
code to switch into kernel state and then exit cleanly after the 
patch is applied. 


.TITLE PATCHER - Apply RSX Exec Patches 
.IDENT /01.00/ 

.MCALL SWSTKS,EXIT$S 

PATCH:: SWSTKS 10$ 

; Install dynamic system patches 

All registers are available at this point. 

MOV #"GL, SSYSNM ;; Change the System Name 

MOV #"IN, SSYSNM+2 ;; to “GLINCH" 

MOV #"CH, SSYSNM+4 

; The patch is now installed. Return to user state. 

RETURN ;; Return to user state 

10$: EXITSS ; and split. 

.END PATCH 


The following corrmand lines assemble and Task Build the patcher 
program: 


MAC PATCHER,PATCHER/-SP=LB:[11,10]RSXMC.MAC,SY:'<UIC>'PATCHER 
TKB PATCHER/PR/-CP,PATCHER=PATCHER,LB:[1,54]RSX11M.STB/SS 


Once the basic PATCHER program is created, it can be used for 
all sorts of things in the RSX Exec. Examples are included below. 
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Some are serious, some frivolous. The examples are just those lines 
to be inserted into the PATCHER program. 


< < < WARN I NG WARN I NG WARN I NG WARN I NG WARN I NG WARN I NG > > > 

The examples shown below could cause a system to crash or 
otherwise malfunction. DO NOT try them just to "see what 
happens". The examples are for illustration purposes only. 


To change the system clock frequency to 50 Hz.: 
MOVB #50.STKPS 


To permanently set Event Flag 32.: 

BIS #1,$COMEF 

To cause the Exec to forget that UMRs (Unibus Mapping Registers) are 
present: 

BIC #HF.UBM,$FMASK 


Severa I possibilities for creative hacking come to mind as well, 
such as changing the system clock to 23 Hz, or changing the system 
name every five seconds, using a rotating table of names. (Fun, but 
it doesn't show up on RMD). 

A more extended use of the PATCHER program is a tweak I have 
been applying to RSX systems ever since I discovered that the 
preaI I ocated I/O Packet list isn't really preallocated. I/O packets, 
up to the limit specified via a SYSGEN question, are left allocated 
upon their first use. Once an I/O packet is allocated by a device 
driver it is entered in the list of permanently allocated packets. 
Two problems are encountered with this feature: 

The preallocated maximum may be too low; if a SET /MAXPKT corrmand 
responds with two identical numbers, the system could probably use 
a few more preallocated packets. 

The packets are not really preallocated, but are allocated when 
needed and then left in a list. While this is a nice run time 
optimization for RSX, it tends to leave preallocated packets 
scattered all over primary POOL, leaving POOL more fragmented than 
it could otherwise be. 

My solution to these problems is the following program. It 
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first changes the maximum number of packets to be left preallocated, 
and then forces their allocation. It then deallocates them, leaving 
the maximum number entered in the preallocated I/O packet list. 
Since the allocation/deallocation is done in a Ioop running in 
Executive state, the packets are most likely allocated immediately 
adjacent to each other, and are located in a bunch at the bottom of 
POOL . 


.TITLE FIXPKT - Allocate Preallocated Packets 
.IDENT /01.00/ 

.MCALL SW5TKS,EX IT$S,CRASH 

This program allocates alI the possible Pre-AIlocated 
RSX I/O Packets, leaving them in a contiguous bunch 
at the bottom of POOL. 

It optionally enables the user to adjust the maximum 
number of packets to be left in the preallocated list. 

Corrmand lines for creation: 

MAC FIXPKT,FIXPKT/-SP=LB:[11,10]RSXMC.MAC,SY:'<UIC>'FIXPKT 
TKB FIXPKT/PR/-CP,FIXPKT=FIXPKT,LB:[1,54]RSX11M.STB/SS 

Comments begun with double semicolons (;;) indicate code 
which executes in kernel mode. 


START: 

: MOV 

#PKTS,R5 


SWST K $ 

GOTTEM 


MOVB 

#16.,$PKMAX 


MOVB 

$ PKMAX,R4 

10$ : 

CALL 

$ALPKT 


BCC 

CRASH 

20$ 

20$ : 

MOV 

R0,(R5) + 


SOB 

R4,10$ 


MOVB 

$PKMAX,R4 

30$ : 

MOV 

-(R5),R0 


CALL 

$DEPKT 


SOB 

RETURN 

R4,30$ 


GOTTEM: EXITSS 


; Point at packet list 
; enter system state 

; ; Change Maximum. 

; ; How many are there? 

;; allocate one. 

; ; continue if ok. 

;; else crash system. 

;; stash packet address 
; ; see if more to do. 

;; now de-aI locate packets. 
;; going backward thru list 
;; and de-aI locate 'em 
;; all of 'em 
;; back to user state. 

; all done. 


; Packet address list 

PKTS: . BLKW 256. 
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END 


START 


F77 Compiler Bug 

Nora K. Narum 
Philip Morris, USA 
PO Box 26603 
JRC 41-1 

Richmond, VA 23261 


We discovered an interesting problem in the Fortran-77 compiler 
when we patched it up to RSX 3.0 Update C level. If you have two 
successive single quotes within a quoted string in a PARAMETER 
statement, for example - 


Program QUOTE 
Integer X,Y 
Character*19 FMT1 

Parameter ( FMT1 = '(IX,12.2,' 12.2)' ) 

X = 12 
Y = 35 

Write (UNIT = 5,FMT = FMT1) X, Y 
End 


the quote processing is incorrect. The above program should print 
"12::35". Instead, it prints "12:35". 

Apparently, when the compiler recognizes the second quote, it 
gobbles both the quote character and the character fol lowing it. 
This can lead to compile errors later, if you're lucky, or just to 
unexpected results at run time. 

We have SPRed this problem, and Digital is working on it. In 
the meantime, we're working around it, and trying not to make changes 
wh ich will have to be changed back when the comp i Ie r is fixed. Most 
of our uses of the quotes inside quotes come from FORMAT statements 
inside PARAMETER statements. For those, we're falling back to 
Hollerith constants to replace the quoted strings. 

Using this technique, the program above becomes: 


Program QUOTE 
Integer X,Y 


n ^ X - C 


( IX, 12.2,2H: : , 12.2) ' ) 


Character * 19 FMT1 
Parameter ( FMT1 = 

X - 12 
Y = 35 

Write (UNIT = 5,FMT = FMT1) X, Y 
End 


Letter to the Editor 

James Bostwi ck 
Cargi I I , Incorporated 
PO Box 9300 
Minneapolis, MN 55440 


I am very concerned by the handling of the recent DECUS Board of 
Directors election. The treatment of candidates in the flyer which 
accompanied the election ballot was no less than appalling. 

Specifically, the flyer shows favoritism toward the LDEC 
approved candidates, while carefully implying that the petitioners 
are somewhat less than equal. This may be in strict keeping with the 
bylaws, but it is no way to run a fair election. There are certain 
areas of the globe where one only votes for "approved" candidates 
but I refuse to believe that DECUS is among them. 

It should also be noted that DECUS specifically prohibits any 
form of "campaigning" in its official publications. If nothing eIse, 
LDEC is guilty of violating this policy in its presentation of the 
slate of candidates as "approved" or "not approved". If I had sent a 
pre-election letter to this newsletter stating that I heartily 
approved of thus-and-so for DECUS board, it would have been in 
violation of policy and would not have been published. The least 
LDEC can do is abide by its own pol icie s . 

If, in fact, such cava I ier treatment of candidates is within the 
bylaws of DECUS, those bylaws should be changed immediately. Once a 
candidate has gained a place on the ballot, any distinction be tween 
LDEC approval and piacemen t by pet it ion should be eliminated. The 
implication that petitioners are somehow less worthy than "approved" 
nominees is grossly unfair, not to mention misleading. 

The amazing thing about the "dual slate" of candidates in this 
case is the lack of distinction in qualifications between the "LDEC 
approved nominees and those who had to force their names on the 

ballot. Perusal of the nominees' statements shows the three 

petitioners to be quite as qualified for consideration as Board 

membe rs as the other nomi nee s. Why we re such em inently qualified 


RSX-9 



individuals not selected as candidates? 

It is disturbing to note that two of the petitioners openly 
state concerns with the direction of the "New DECUS" . Furthermore, 
with one exception, the "approved" candidates are all intimately 
connected with the "New DECUS". Could it be that the petitioners are 
unacceptable for purely political reasons? 

Could it be, in fact, that LDEC selects candidates as much for 
their acceptability to LDEC itself as for their qualifications to sit 
on the Board of Directors of DECUS? Could it be that LDEC is less 
than objective in carrying out its role of recruting and nominating 
candidates for the Board? I certainly hope not. However, the 
evidence of the election pamphlet raises serious doubts. 

Let me state emphatically that I have no problem with ANY of the 
candidates on the ballot. All appear qualified for the position to 
which they aspire. My problem is specificaI Iy wi th LDEC and the way 
in which the candidates were presented to DECUS membership. At a 
minimum, those sections of the bylaws pertaining to conduct of 
elections, and the policies which guide LDEC in carrying out election 
duties require immediate and thorough review. The least that the 
"New DECUS" can do for its membership is conduct fair and unbiased 
eIections. 


Missing TKB Global Symbol “ERRDEF” 

Nora K. Narum 
Philip Morris, USA 
PO Box 26603 
JRC 41-1 

Richmond, VA 23261 


In the November, 1986 issue of The Software Dispatch, DEC 
documents a problem with the high-level language interface to the 
Executive directives in which tasks build with an undefined reference 
to ERRDEF. This probI em originated in Update C, and is (allegedly) 
fixed in Update D. 

DEC suggests two ways to work around this problem. The first, 
and simplest, is to ignore it. We have trouble doing that because 
the undefined symbol causes TKB to return an exit status other than 
success, and that upsets our automated application-system builder. 

The second solution offered by DEC is to include a GBLDEF option 
in each task's TKB command file so that the ERRDEF symbol is 
resolved. V\fe don't like that one either, because we have a large 


base of installed tasks and associated task-build command files, and 
adding the GBLDEF to each one is a lot of work. 

What we've done is to include an additional module in SYSLIB.OLB 
which provides a definition for ERRDEF. We created a very short 
MACRO program: 


.TITLE ERRDEF 

ERRDEF:: 

.END 


We assemble it, then insert the resulting module into SYSLIB.OLB 
(LBR LB:[1,1]SYSLIB.OLB=ERRDEF.OBJ/EP/IN). Now our tasks bui Id wi th 
their old command files and no unresolved symbols. 


Recovery of BRU Multi-Volume Tape Sets 

David Maden 
Computer Section 

Swiss Institute for Nuclear Research 
CH-5234 Vi I I igen 
Swi tzerI and 


1. The ProbIem 

Careful reading of the RSX Utilities Manual reveals that the /AP 
switch with BRU is valid only to append backup sets to the end of a 
single volume magnetic tape set. Once backup sets extend to more 
than one tape, the /AP switch is no longer permitted. The manual 
implies that use of the /AP switch in these circumstances should 
result in an error message. 

Unfortunately, certain versions of BRU (V07.24 of RSX-11M 
V4.2/B, in particular) do not enforce this restriction. The result, 
for the unwary, can be a mu Iti-voIume magnetic tape set containing 
backup sets which cannot be restored using BRU, since BRU is adamant 
that a backup set used in a restore operation must start on the first 
volume of a multi-volume backup set. 

The purpose of this note is to describe a means of recovering 
these backup sets. The recovery procedure appears to work 
satisfactorily for backup sets completely contained on a single 
volume. The recovery of backup sets which not only start after the 
first volume but also span more than one volume is not solved 
completely, although a procedure which appears to achieve partial 


RSX-10 


RSX-11 



recovery of such backup sets is described. 

The recovery procedure requires access to a VAX/VMS system with 
two magnetic tape drives of density compatible with the RSX generated 
BRU tape. Tests have been made using an RSX-11M V4.2/B system and a 
VMS V4.5 system. 


2. The So Iution 

In the interest of clarity, let us consider the case of a 


3-volume magnetic 

tape set 

Assume that the contents of the volumes 

are as foilows : 



Tape 1: File 1 

/BAC:BB1, 

, part 1 of 2 

Tape 2: File 1 

/BAC:BB1, 

, part 2 of 2 

Fi le 2 

/BAC:BB2, 

, complete 

Fi le 3 

/BAC:BB3, 

. part 1 of 2 

Tape 3: File 1 

/BAC:BB3, 

part 2 of 2 

Given this volume set. 

BRU is able to restore backup set BB1 


normally, but attempts to restore backup sets BB2 or BB3 fail. In 
this section, a procedure is described for recovering BB2 (i.e., a 
backup set which is completely contained on a single volume). The 
recovery of backup set BB3 is described in section 3. 

The recovery procedure for BB2 is to copy the backup set to 
another tape in such a way that it appears to BRU to be an appended 
backup set on a single volume tape set. All attempts to perform the 
required copy using PIP on RSX-11M failed, because, while BRU writes 
ANSI type labels on magnetic tapes, it does not follow standard ANSI 
procedure for encoding the record lengths. As a result, the more 
forgiving VAX/VMS COPY corrmand must be used. The procedure is as 
foilows : 


1. On an RSX system, initialize a target magnetic tape using 
BRU. Assuming that UFD LB:[g,m] is a nonexistent UFD and 
that MTnn: is a tape drive available on the RSX system, 
load the tape on the drive and issue the corrmand: 

BRU /MOU LB:[g,m] MTnn: 

The following messages will appear: 

BRU - Starting Tape 1 on MTnn: 

BRU - End of Tape 1 on MTnn: 

BRU — * WARNING * No files found 
BRU - Completed 


Note that the target tape must be initialized using BRU 
on an RSX system. Use of the INI corrmand under RSX or VMS 
is inadequate. 

2. Log in to the VMS system and allocate two tape drives: 

ALL MTAm: 

ALL MTAn: 

Load the tape containing backup set BB2 on MTAm: and load 

the target tape on MTAn:. 

3. Mount the two tapes using the commands: 

MOU MTAm: /OVER= (CWNER , I D) 

MOU MTAn: /OVER=(OWNER,ID) /BLOCK=4144 

Note the specification of the blocksize on the output 
magnetic tape. 

4. Copy BB2 to the target magnetic tape using the corrmand: 

COPY MTAm: "BB2'' MTAn: /LOG 
Note that the quotation marks are required syntax. 


The resulting target tape can be read by BRU on an RSX system 
and the backup set, BB2, can be restored to disk in the usual way. 


3. Recovery Procedure for a Split Backup Set 

If the above recovery procedure is attempted for a backup set 
such as BB3 which is split between two tape volumes, a VAX operator 
request to mount the continuation volume of BB3 is obtained at the 
end of tape 2. Unfortunately, the format of tape 3 is such that it 
is impossible to satisfy this request, and the recovery procedure 
fails. No completely successful method of recovering such backup 
sets has been found, though the following method has achieved partial 
recovery. It is described here as stimulation for further 
inves tigation. 

The purpose of the procedure is firstly to modify tape 2 so that 
VMS COPY believes that there is no continuation tape for BB3. The 
procedure of section 2 is then followed to copy the first part of BB3 
to a target tape which has been initia I ized wi th BRU. The target 
tape is then modified so that it again has a format corresponding to 
a BRU backup set which has been continued on a second volume. The 
resulting tape, together with tape 3, is used as input to BRU to 
restore BB3 to a disk. 

The normal format of an ANSI format tape which continues onto a 
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subsequent tape is, according to the VMS documentation, as follows: 

HDR1 HDR2 * ...Data... * EOV1 EOV2 

where * represents a tape mark, and EOV1 and EOV2 are 80-byte records 
containing the ASCII strings "EOVV and "EOV2" in the first 4 bytes, 
respectiveIy. 

For a tape which does not continue, the format is: 


HDR1 HDR2 * ...Data... * EOF1 EOF2 


EOF 1 and EOF2 are also 80-byte records with the same structure as EOV 
labels except for the substitution of "F" for "V" in the third byte. 
The recovery procedure is therefore as follows: 

1. Modify tape 2 so that the EOV1 and EOV2 labels are converted 
to E0F1 and EOF2 labels. This can be done via a simple 
Macro program. Our method, however, was to use the SIG tape 
copy program TPC to copy the tape to a disk file. DMP was 
then used to locate the EOV labels so that they could be 
patched into EOF labels by ZAP. A new tape was finally 
written using TPC. (The new tape must be longer than the 
original so that TPC does not give trouble with end of 
tape.) 


2. 

Use the procedure of section 2 to copy the 
backup set BB3 to a new target tape. 

first 

part 

of 

3. 

Reverse step 1 with the target tape to 
labels back into EOV labels. 

conver t 

the 

EOF 

4. 

Use the resulting tape together with the or 
input to BRU to restore the backup set. 

i g i na 1 

tape 3 

as 


Plausible though it seems, this recovery procedure for a split 
backup set is not perfect. During tests made at SIN during the 
preparation of this note (no case has yet arisen here where such a 
recovery is necessary, so no great amount of time has been invested 
in finding a complete solution), BRU reported lost data records at 
the start of the second part of the backup set during the restore 
operation. Some files were missing on the restored disk. Most files 
however, were found to be present, correct and complete. 

The reason for these problems presumably results from the 
simplistic patching of the first tape in the backup set which, in 
turn, is a result of the fact that the BRU tape format is unpublished 
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(at least for the lesser mortals outside DEC). Despite thes< 
limitations, the procedure is published here as incentive to stud> 
the problem further should the need be sufficiently pressing. 


Response to December “Bag of Tricks” 

W. B. Langdon 
CERL 

Kelvin Avenue 
Leather head 
Surrey KT22 7SE 
Eng I and 

The following is a response to the article in the December 198t 
issue ’Bag of Tricks” about tracking task build dates. Thanks to tht 
submit tor for these comments. -- The Editor 

The December 1986 issue of The Multi-Tasker . with the "Bag ol 
Tricks: MACRO-11" article by Barton Bruce was very interesting. 

It is important to note that the $$DBTS .PSECT and $DBTS global 
label must be placed in the task's root segment, if the task ij 
over laid. 

Those concerned with the size of the root (all of us?) can place 
the code which converts the stored date and time to ASCII into 2 
separate module. The resulting module can then be placed in ar 
overlay segment. This approach uses only 40 decimal bytes in the 
root segment. 


RSX SIG Leadership Chart 

Ed Cetron 

SIG Long Range Planning Coordinator 


The SIG leadership chart was revamped at the Spring ’’Woods’ 
meeting in February. This chart would have accompanied the meeting 
report, but arrived just one day too late to make it in. 
Shucks! - - The Editor 
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Charlotte Allen 



Files-11 On-Disk Structure Specification 

Digital Equipment Corporation 
Maynard, MA 


This article is presented to lay the foundation for an article 
scheduled later this year on an ODS - 2 AGP for RSX . -- 7 'he Editor 


Files-11 On-Disk Structure Specification 


15-Jan-1979 
Edited 30-Mar-1987 


Copyright (c) 1979 

Digital Equipment Corporation, Maynard, Mass. 


The material included in this functional specification, including but 
not limited to instruction times and operating speeds, is for 
informational purposes only. All such material is subject to change 
without notice. Consequently, Digital Equipment Corporation makes no 
claim and shall not be liable for its accuracy. 


This software is furnished under a license for use only on a single 
computer system and may be copied only with the inclusion of the 
above copyright notice. This software, or any other copies thereof, 
may not be provided or otherwise made available to any other person 
except for use on such system and to one who agrees to these license 
terms. Title to and ownership of the software shall at all times 
remain in Digital Equipment Corporation. 

The information in this document is subject to change without notice 
and should not be construed as a commitment by Digital Equipment 
Corporation. 

Digital Equipment Corporation assumes no responsibility for the use 
or reliability of its software on equipment which is not supplied by 
Digital Equipment Corporation. 
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1.0 Scope 


This document is a specification of the on-med i a structure used 
by Files-11. Files-11 is a general purpose file structure intended 
to be the standard file structure for all medium to large PDP-11 
systems. Small systems such as RT-11 are specifically excluded 
because the complexity of Files-11 imposes too great a burden on 
their simplicity and small size. 

This document describes structure level 2 of Files-11, also 
referred to as ODS-2 (on-disk structure 2). It contains feature and 
reliability improvements over structure level 1 (ODS-1). This 
version of the specification is subsetted to describe only the 
features implemented at present (VMS Version 1.5). 


1.1 Conventions 


All numerical values in this document are in decimal radix, 
unless indicated otherwise. 

Within the file structure are fields containing binary integers 
of various lengths. Unless otherwise indicated, all these fields are 
in the standard numerical format, which means that the most 
significant bits are stored in the highest numbered address. 

In the descriptions of various structures on the disk, there are 
fields labelled "not used". These fields must be zero, so that they 
can be made nonzero for future use. Since they are reserved for 
future use, programs reading these structures should not assume that 
these fields are in fact zero. 


2.0 Medium 


Files-11 is a structure imposed on a medium. That medium must 
have certain properties, which are described in the following 
section. Generally speaking, block addressable storage devices such 
as disks and DECtape are suitable for Files-11; hence, Files-11 
structured media are generically referred to as disks. 


2.1 Vo I ume 


The basic medium that carries a Files-11 structure is referred 
to as a volume. A volume (also often referred to as a unit) is 


defined as an ordered set of logical blocks. A logical block is an 
array of 512 8-bit bytes. The logical blocks in a volume are 
consecutively numbered from 0 to (n — 1), where the volume contains n 
logical bIock s. 

The number assigned to a logical block is called its logical 
block number, or LBN. Files-11 is theoretically capable of 
describing volumes up to (2**32) blocks in size. In practice, a 
volume should be at least 100 blocks in size to be useful. 

The logical blocks of a volume must be randomly addressable. 
The volume must also allow transfers of any length up to 65K bytes, 
in multiples of four bytes. When a transfer is longer than 512 
bytes, consecutively numbered logical blocks are transferred until 
the byte count is satisfied. In other words, the volume can be 
viewed as a partitioned array of bytes. It must allow reads and 
writes of arrays of any length less than 65K bytes, provided that 
they start on a logical block boundary and that the length is a 
multiple of four bytes. When only part of a block is written, the 
contents of the remainder of that logical block are undefined. 

The logical blocks of a volume are grouped into clusters. The 
cluster is the basic unit of space allocation on the volume. Each 
cluster contains one or more logical blocks; the number of blocks in 
a cluster is known as the volume cluster factor, or storage map 
cluster factor. 

A volume is identified as a Files-11 volume by the home block. 
The home block is located at a defined physical location on the 
volume, and is identified by the presence of checksums and 
predictable values. The home block contains a volume label, which is 
a string of up to 12 ASCII characters. The characters are restricted 
to the printing ASCII set (i.e., excluding control characters and 
RUBOUT). Further, it is recommended that volume labels be restricted 
to a Iphanume rics only to avoid conflicts with the command languages 
of supporting systems. The volume label of a volume may not be null. 


2.2 Vo Iume Sets 


A volume set is a collection of related volumes that are 
normally treated as one logical device in the usual operating system 
concept. Each unit contains its own Files-11 structure; however, 
files on the various volumes in a volume set may be referenced with a 
relative volume number, which uniquely determines which volume in the 
set the file is located on. 

A volume set has an associated structure name, which is a string 
of up to 12 ASCII characters identifying the volume set. The 
character set limitations of the volume label also apply to the 
structure name. The structure name may not be nulI. 
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2.2.1 Tightly Coupled Volume Set 

A tightly coupled volume set is a volume set which is consistent 
and seIf-identifying. The volume labels of the volumes making up the 
set must be unique within the set, and must be different from the 
structure name. Relative volume one of the set contains a file which 
lists the volume labels of all the volumes in the set, thus 
associating volume labels with relative volume numbers. Each volume 
is identified as being part of the set by carrying the structure 
name, its volume label, and its relative volume number. 


2.2.2 Loosely Coupled Volume Set 

A loosely coupled volume set is a collection of volumes which is 
not seIf-identifying . There is no file listing the volume labels. 
Only one file may cross from any one vol ume in the set to another, 
and files in the set which cross volumes may be processed only 
sequentially. Correct sequencing of the volumes that hold a 
particular file is the responsibility of the system operator. There 
are checks that catch most handling errors, but they cannot be 
foolproof. The purpose of the loosely coupled volume set is to 
emu late mu I t i -vo I ume magtape , and a I I ow a file to be read or written 
sequent ially with only one vol ume mounted at a t ime . 


3.0 Files 


Any data in a volume or volume set that are of any interest 
(i.e., all blocks not available for allocation) are contained in a 
file. A file is an ordered set of virtual blocks, where a virtual 
block is an array of 512 8-bit bytes. The virtual blocks of a file 
are consecutively numbered from 1 to n, where n is the highest 
numbered block allocated to the file. 

The number assigned to a virtual block is called its virtual 
block number, or VBN. Virtual blocks are mapped to unique logical 
blocks in the volume set by Files-11. Virtual blocks may be 
processed in the same manner as logical blocks. Any array of bytes 
less than 65K in length may be read or written, provided that the 
transfer starts on a virtual block boundary and that its length is a 
multiple of four bytes. 

For most files, all VBNs less than or equal to the highest VBN 
allocated map to some LBN in the volume set. Such files are said to 
be dense. Files which are sparse contain virtual blocks which are 
not allocated logical blocks. 


3.1 File ID 


Each file in a volume set is uniquely identified by a File ID. 

A File ID is a binary value consisting of 48 bits (3 PDP-11 words). 
It is supplied by the file system when the file is created, and must 
be supplied by the user whenever he wishes to reference a particular 
file. 

The three words of the File ID are used as follows: 

Word 1 File Number 

Locates the file within a particular volume of the volume 
set. File numbers ordinarily lie in the range 1 through 
65,535. The set of file numbers on a unit is moderately (but 
not totally) dense; at any instant in time, a file number 
uniquely identifies one fi le wi thin that volume. 

Ward 2 File Sequence Number 

Identifies the current use of an individual file number on a 
volume. File numbers are reused; when a file is deleted, 
its file number becomes available for future use for some 
other file. Each time a file number is reused, a different 
file sequence number is assigned to distinguish the uses of 
that file number. The file sequence number is essential 
since is is perfectly legal for users to remember and attempt 
to use a File ID after that file is deleted. 

V\ford 3 Relative Volume Number 

I dentifies which volume of a volume set the file is I ocated 
on. If the volume in question is not a member of a volume 
set, this word is zero. If the volume is part of a volume 
set! then the relative volume number, or RVN, lies in the 
range from 1 to 65,535. In any context where a particular 
volume of a volume set can be identified as the "current 
volume", such as a file extension linkage, a relative volume 
number of zero means the current volume. When a file is 
referred to in the context of the volume on which it resides, 
it should be referred to with a relative volume number of 
zero, regardless of the RVN assigned to that volume. 

File Number Extension 

If the maximum number of files permitted on the volume (as 
recorded in the home block) is greater than 65,535, then the 
high byte of the relative volume number becomes a high order 
extension to the file number. The volume set size is then 
limited to 255 volumes, while the range of allowable file 
numbers extends from 1 to (2**24)-1. When 24-bit file 
numbers are used, the file system should not create files 
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whose file number is an integer multiple of 65,536; i.e., 
whose low 16 bits are zero. Such file numbers break existing 
PDP-11 software such as FCS-11. 


3.2 File Header 


Each file on a Files-11 volume is described by a file header. 
The file header is a block containing all information necessary to 
access the file. It is not part of the file; rather, it is 
contained in the volume's index file. The header block is organized 
into six areas, of which the first five are variable in size. 


3.2.1 Header Area 

The information in the header area permits the file system to 
verify that this block is in fact a file header and is the particular 
header sought by the user. It contains the file number and file 
sequence number of the file, as well as its ownership and protection 
codes. This area also contains offsets to the other areas of the 
file header, thus defining their size. 


3.2.2 Ident Area 

The ident area of a file header contains identification and 
accounting data about the file. Stored here are the primary name of 
the file; creation date and time; revision count, date and time; 
and expiration date. 


3.2.3 Map Area 

The map area describes the mapp ing of virtual blocks of the file 
to logical blocks of the volume. The mapping data consists of a list 
of retrieval pointers. Each retrieval pointer describes one group of 
consecutively numbered logical blocks allocated to the file. 
Retrieval pointers are arranged in the order of the virtual blocks 
they represent. 


3.2.4 Access Control List 

The access control list is an optional area that contains a list 
of users allowed access to the file. The access control list makes 
it possible to describe user communities for a particular file that 
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cannot be expressed with the regular protection classes. 


3.2.5 Reserved Area 

This optional area is reserved for used by CSS or special 
applications. It is not used by standard Files-11 systems. 


3.2.6 End Checksum 

The last two bytes of the file header contain a 16-bit additive 
checksum of the preceding 255 header words. The checksum is used to 
help verify that the block is in fact a file header. 


3.3 Multi-Header Files 


Since the file header is of fixed size, it is inevitable that 
for some files the mapping information does not fit in the allocated 
space. A file with a large amount of mapping data is therefore 
represented with a chain of file headers. Each header maps a 
consecutive set of virtual blocks; the extension linkage in the 
header area links the headers together in order of ascending virtual 
block numbers. The extension pointer in each file header is the File 
ID of the next header in sequence. 


3.4 Multi-Vo Iume Files 


Multiple headers are also needed for files spanning units in a 
volume set. A header may only map logical blocks located on its 
volume; therefore, a mu Iti-voI ume file is represented by headers on 
all voIumes con taining portions of that file. In a multi-voI ume file 
on a loosely coupled volume set, the File ID of the first header on 
each continuation volume always has the value 7,7,n, where n is the 
RVN of the volume on which the file starts plus the number of 
preceding volumes containing portions of the file. 


3.5 File Header - Detailed Description 


This section describes in detail the items contained in the file 
header. Each item is identified by a symbol which represents the 
offset address of that item within its area in the file header. Any 


RSX-2 



item may be located in the file header by locating the area to which 
it belongs, and then adding the value of its offset address. Users 
who concern themselves with the contents of file headers are strongly 
urged to use the offset symbols. 

The symbols may be defined in PDP-11 (and VAX compatibility 
mode) assembly language programs by calling and invoking the macro 
FHDL2$, which may be found in the macro library of any system that 
supports Files-11. Alternatively, one may find the macro in the file 
OD2MAC.MAC. 

VAX native mode assembly language programs can define a 
corresponding set of file header offsets by invoking the macros 
SFH2DEF, SFI2DEF and $FM2DEF. These macros are located in the macro 
library LIB.MLB. Source for these macros is located in the file 
FI 1DEF.MAR. 


3.5.1 Validity 

A valid file header is defined by the following rules: 

1. The contents of H. I DOF is no less that the offset H.FCWN/2. 

2. The four offset bytes are related in the manner: (H.IDOF) 

.LE. (H.MPOF) .LE. (H.ACOF) .LE. (H.RSOF ) . 

3. The high byte of H.FLEV contains the value 2. 

4. The low byte of H.FLEV contains a value greater than or 
equaI to 1. 

5. The word H.FNUM contains the file number. 

6. The word H.FSEQ contains the f i le sequence number. 

7. The high byte of H.FRVN contains the extended part of the 
file number, if any. 

8. The contents of the byte H.USE must be less than or equal to 
(H.ACOF) - (H.MPOF). 


A deleted file header conforms to the format of a valid file 
header with the following exceptions: 

1. SC.MDL is set in H.FCHA. 

2. H.FNUM and H.FCHA contain zero. 

3. The file header checksum contains zero. 
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3.5.2 Header Area Description 

The header area of the file header always starts at byte 0. It 
contains the basic information needed for checking the validity of 
accesses to the file. 


3.5.2.1 H.IDOF 1 byte Ident Area Offset 

This byte contains the number of 16-bit words between the 
start of the file header and the start of the ident area. 
It defines the location of the ident area and the size of 
the header area. 


3.5.2.2 H.MPOF 1 byte Map Area Offset 

This byte contains the number of 16-bit words between the 
start of the file header and the start of the map area. It 
defines the location of the map area and, together with 
H.IDOF, the size of the ident area. 


3.5.2.3 H.ACOF 1 byte Access Control List Offset 

This byte contains the number of 16-bit words between the 
start of the file header and the start of the access control 
list. It defines the location of the ACL and, together with 
H.MPOF, the size of the map area. 


3.5.2.4 H.RSOF 1 byte Reserved Area Offset 

This byte contains the number of 16-bit words between the 
start of the file header and the start of the reserved area. 
The reserved area is not used by Files-11 itself, and may be 
used by CSS or special applications. Together with H.ACOF, 
this byte defines the size of the access control list. The 
size of the reserved area is implied by the contents of 
H.RSOF and the end of the header block. 


The presence of the ident, map, ACL and reserved areas are 
optional. Absence of any area is signalled not by a zero offset, but 
by equality of the two offsets that define the area's size. All five 
areas are variable in length; implementations of Files-11 must check 
the length of a particular area before attempting to reference a 
par ticuIar entry. 
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3.5.2.5 H.FSEG 2 bytes Extension Segment Number 


3.5.2.10 H.EFNU 2 bytes Extension File Number 


This word contains the value n, where this header is the 
(n+1)th header of the file; i.e., headers of a file are 
numbered sequentially starting with 0. 


3.5.2.6 H.FLEV 2 bytes Structure Level and Version 

The file structure level and version are used to identify 
different versions of Files-11 as they affect the structure 
of the file header. This permits upward compatibility of 
file structures as Files-11 evolves, in that the structure 
level word identifies the version of Files-11 that created 
this particuIar file. 

This document describes structure level 2 of Files-11. The 
high byte of H.FLEV must contain the value 2. The low byte 
contains the version number, which must be greater than or 
equal to 1. The version number is incremented whenever 
compatible additions are made to the Fi les-11 structure that 
may be safely ignored by an old version of the file system. 
This document describes version 1 of structure level 2. 


3.5.2.7 H.FNUM 2 bytes File Number 

This word contains the file number of the file. 


3.5.2.8 H.FSEQ 2 bytes File Sequence Number 

This word contains the file sequence number of the file. 


3.5.2.9 H.FRVN 2 bytes Relative Volume Number 

This word holds part of the third word of the Fi le ID when 
appropriate. This is usually referred to as the relative 
volume number. VWien used as such (i.e., to indicate the 
volume of a volume set), it is not recorded in the file 
header , since the RVN of a vo I ume may change during a file's 
I ife, and the RVN portion of a Fi le ID may be zero or 
nonzero, depending on the context. 

However, when the high byte of the RVN is used as an 
extension to the file number, it is recorded in the high 
byte of this word. The low byte of H.FRVN is always zero. 


This word contains the file number of the next sequential 
extension header for this file. If there is no extension 
header, this word contains zero. 


3.5.2.11 H.EFSQ 2 bytes Extension File Sequence Number 

This word contains the file sequence number of the next 
sequential extension header for this file. If there is no 
extension header, this word contains zero. 


3.5.2.12 H.ERVN 2 bytes Extension Relative Volume Number 

This word contains the relative volume number of the volume 
in the volume set that contains the next sequential 
extension header for this file. If there is no extension 
header, or if the extension header is located on the same 
volume as this header, this word contains zero. 


3.5.2.13 H.UFAT 32 bytes User Attribute Area 

This area is used by the record manager, or any other 
higher level access mechanism, to store information 
necessary for processing the file (e.g., record control 
data, EOF mark, etc.). 


3.5.2.14 H.FCHA 4 bytes File Characteristics 

H.UCHA = H.FCHA + 0 User Controlled Characteristics 
H.SCHA = H.FCHA + 1 Systern ControI Ied Characteristics 

The user controlled characteristics byte contains the 
foI Iowi ng flag bits: 

UC.CON Set if the file is logically contiguous; i.e., if 
for all virtual blocks in the file, virtual block i 
maps to logical block (k+i) on one volume for some 
constant k. This bit may be implicitly set or 
cleared by file system operations that allocate 
space to the file; the user may only clear it 
exp I ici11y. 

UC.CNB Set if the file is allocated contiguous best 
effort; i.e., as contiguous as possible. 


RSX-26 


RSX-27 



UC.DLK Set if the file is deaccess-Iocked. This bit is a 
flag warning that the f i le was not properly closed 
and may contain inconsistent data. Access to the 
file is denied if this bit is set. 

UC.RCK Set if the file is read-checked. All read 

operations on the file, including reads of the file 
header(s), are performed with a read, read-compare 
to assure data integrity. 

UC .W3K Set if the file is write-checked. All write 

operations on the file, including modifications of 
the file header(s), are performed with a write, 
read-compare to assure data integrity. 

UC.NID Set if incremental dump (backup) is disabled for 

this file. 

UC.\A£C Set if the file is to be write-back cached; i.e., 
if a cache is used for file data, data written by a 
user are written back to the disk only when it is 
removed from the cache. Clear for write-through 
cache operation. 

The second byte of the file characteristics words is 

historically known as the system controlled file 

characteristics. It contains the following flag bits, 

defined as referenced within the byte: 

SC.MDL Set if the file is marked for delete. If this bit 
is set, further accesses to the file are denied, 
and the file is physically deleted when no users 
are accessing it. 

SC.BAD Set if there is a bad data biock in the file. This 
bit is unimp I emented. It is intended for dynamic 
bad bIock hand ling. 

SC.DIR Set if the file is a directory. 

SC.ACL Set if an access control list exists for this file. 

SC.CHK Set if the file header checksum was not computed. 

If this bit is set, the checksum word must contain 
the octal value 125252. This "feature" is for 
sma I I systems that cannot afford the mi I I i second or 
two required to compute the header checksum. Its 
use is strongly discouraged. 


3.5.2.15 2 bytes Unused 


3.5.2.16 H.USE 1 byte Map Words in Use 

This byte contains a count of the number of map area words 
currently in use. 


3.5.2.17 H.PRIV 1 byte Accessor Privilege Level 

This byte defines the lowest privilege level at which an 
accessor must be running to be allowed access to the file. 
Each privilege level is a two-bit integer; zero is the 
I owes t privilege and 3 is the highest. Privilege I eve Is 
may be assigned separately to the basic file access modes, 
using the following bit assignment in this byte: 

Read Bits 0-1 
Write Bits 2-3 
Execute Bits 4-5 
Delete Bits 6-7 

An operating system should map its privilege level coding 
onto this code in the smoothest manner possible. For 
example, the four access modes of VMS - user, supervisor, 
exec, and kernel - are codes 0 through 3, respectively. A 
system such as RSX-11M which has only two levels 
(privileged and non-privileged) shouId map the two onto 3 
and 0, respectiveIy. 

Privilege levels are meant to confine access to the 
contents of file to suitably trustworthy procedures. Thus, 
a user might be denied the ability to write a record 
structured file directly (on a vir tuaI block basis), but 
wouId be permi t ted to wr ite the file through the record 
manager, which would be suitably privileged. 

For a record structured file, an appropriate set of 
privilege levels is 0,2,0,0, expressed in the order Read - 
Write - Execute - Delete. 


3.5.2.18 H.FCWN 2 bytes File CWner UIC 

H. PROG = H.FOWM + 0 Programmer (Member) Number 
H.PROJ = H.FGA/N + 2 Project (Group) Number 

This word contains the binary User Identification Code 
(UIC) of the owner of the file. The file owner is usually 
(but not necessarily) the creator of the file. 
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3.5.2.19 H.FPRO 2 bytes File Protection Code 

This word controls what access all users in the system may 

have to the file. Accessors of a file are categorized 

according to the relationship between the UIC of the 
accessor and the UIC of the owner of the file. Each 

category is controlled by a four bit field in the 

protection word. The category of the accessor is selected 
as foilows : 

System Bits 0 - 3 

The accessor is subject to system protection if the 
project number of the UIC under which he is running 
is 10 octal or I ess. 

Owner Bits 4 -7 

The accessor is subject to owner protection if the 
UIC under which he is running exactly matches the 
file owner UIC. 

Group Bits 8 - 11 

The accessor is subject to group protection if the 
project number of his UIC matches the project 
number of the file owner UIC. 

WarId Bits 12 - 15 

The accessor is subject to world protection if he 
does not fit into any of the above categories. 

Four types of access are defined in Files-11: Read, Write, 
Execute and Delete. Each four bit field in the protection 
word is bit encoded to permit or deny any combination of 
the four types of access to that category of accessors. 
Setting a bit denies that access to that category. The 
bits are defined as follows (these values apply to a 
right-justified protection field): 

FP.RDV Deny read access 
FP.WRV Deny write access 
FP.EXT Deny extend access 
FP.DEL Deny delete access 

When a user attempts to access a file, protection checks 
are performed in all the categories to which he is 
eligible, in the order: System - Owner - Group - War I d. 
The user is granted access to the file if any of the 
categories to which he is eligible grants his access. 

Recommended defaults for file protection for an "open shop" 
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are [ RWD, FW), FW, R ] (expressed in the order of System - 
Owner - Group - War Id, where each letter denotes the 
presence of that permission). Observe that only files 
which contain executable programs should have Execute 
protection enabled. Recommended defaults for a "closed 
shop" system are [ FW),FW3,R,]. 


3.5.2.20 H.BFNU 6 bytes File Header Back Link 

The back link is the File ID of the directory file 
containing the primary directory entry of the file. If the 
file header is an extension header, the back link contains 
the File ID of the primary header. 


3.5.2.21 4 bytes Unused 


3.5.2.22 S.HDHD 74 bytes Size of Header Area 

This symbol represents the total size of the header area 
containing all of the above entries. 


3.5.3 Ident Area Description 

The ident area of the file header begins at the word indicated 
by H. I DOF. It contains identification and accounting data about the 


3.5.3.1 I.FNAM 20 bytes File Name 

This area contains the file name in ASCII. A dot separates 
name from type, and a semicolon separates type from version; 
both are always present. If the name is shorter than 20 
bytes, it is blank-padded; if longer, it is truncated. 


3.5.3.2 I .RVNO 2 bytes Revision Number 

This word contains the revision count of the file in binary. 
The revision count is the number of times the file has been 
accessed for write. 
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3.5.3.3 I .CRDT 8 bytes Creation Date and Time 

These eight bytes contain the date and time at which the 
file was created. The time is expressed in the standard 
internal time format, which is a 64-bit integer representing 
tenths of microseconds elapsed since midnight, 17 November 
1858 ("clunks"). 


3.5.3.4 I.RVDT 8 bytes Revision Date and Time 

The revision date is the date on which the file was last 
deaccessed after being accessed for write. It is expressed 
in the same format as I.CRDT above. 


3.5.3.5 I.EXDT 8 bytes Expiration Date and Time 

These eight bytes contain the date and time at which the 
file becomes eligible to be deleted. The format is the same 
as that of I.CRDT and I.RVDT above. 


3.5.3.6 I.BKDT 8 bytes Backup Date and Time 

These eight bytes contain the date and time at which the 
file was last backed up. The format is the same as that of 
those above. 


3.5.3.7 S.IDHD 36 bytes Size of Ident Area 

This symbol represents the size of the ident area containing 
all of the above entries. 


3.5.4 Map Area Description 

The map area of the file header begins at the word indicated by 
H.MPOF. This area contains the retrieval pointers that actually map 
the virtual blocks of the file to the logical blocks of the volume. 

Each retrieval pointer describes a consecutively numbered group 
of logical blocks allocated to the file. The count field contains 
the binary value n to represent a group of (n+1) logical blocks. The 
logical block number field contains the logical block number of the 
first logical block in the group. 
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Thus, each retrieval pointer maps virtual blocks j through (j+n) 
into logical blocks k through (k+n), where j is the total number plus 
one of virtual blocks represented by all preceding retrieval pointers 
in this and all preceding headers of the file; n is the value 
contained in the count field; and k is the value contained in the 
logical block number field. Observe that j, k, and (n+1) must always 
be integer multiples of the volume cluster factor. 

If the LBN field of a retrieval pointer contains all ones (i.e., 
points to block (2**22)-1 or (2**32)-1, then that retrieval pointer 
represents an unallocated portion of a sparse file. The count field 
then describes the number of unallocated virtual blocks in the normal 
manner . 

There are four formats of retrieval pointers, each identified by 
escape codes. The different formats may be intermixed within a file 
header 


Format 0: Two bytes 

4 - 1 -+ 

I 00 I Placement I 


Format 0 is used to store placement data in the file header. It 
describes the piacement con t roI supplied with the allocation that 
created the following retrieval pointer, allowing the file placement 
to be replicated when the file is copied or backed up and restored. 
Coding of the placement data is undefined. Format 0 is identified by 
bits 15 and 14 of the first word being 00. 


Format 1: Four bytes 

+ - + - + - + 

I 01 I High I Count I 

4.-+-4-+ 

I Low order LBN I 

+-+-+ 

Format 1 provides an 8-bit count field and a 22-bit LBN field. It is 
therefore capable of representing a group of up to 256 blocks on a 
volume up to (2**22) blocks in size. Format 1 is identified by bits 
15 and 14 of the first word being 01. 
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Format 2: Six bytes 


3.5.7 End Checksum Description 
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The header check sum occupies the last two bytes of the file 
header. It is verified every time a header is read, and is 
recomputed every time a header is written. 

If the bit SC.CHK is set in the system controlled 
characteristics word H.SCHA, then the checksum has not been computed, 
and the checksum word must contain the octal value 125252. 


Format 2 provides a 14-bit count field and a 32-bit LBN field. It is 
therefore capable of representing a group of up to 16,384 blocks on a 
volume up to (2**32) blocks in size. Format 2 is identified by bits 3.5.7.1 
15 and 14 of the first word being 10. 


Format 3: Eight bytes 


1111 Coun t, high 

+-+ -+- 

I Count, I ow order 

+ - + - 

I LBN 
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I LBN 
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- + 
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-+ 
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-+ 

I 


H.CKSM 2 bytes Block Checksum 


This word is a simple additive checksum of all other words 
in the block. It is computed by the following PDP-11 
routine or its equivalent: 


10 $ : 


MOV Header-address, R0 

CLR R1 

MOV #255., R2 

ADD (R0)+, R1 

SOB R2, 10$ 

MOV R 1 , (R0) 


+ - +-+ 

Format 3 provides a 30-bit count field and a 32-bit LBN field. It is 
therefore capable of representing a group of up to (2**30) blocks on 
a volume up to (2**32) blocks in size. Format 3 is identified by 
bits 15 and 14 of the first word being 11. 


3.5.8 File Header Layout 

The following is a graphic layout of 
header. 


the fields 


in the file 


Header Area 


3.5.5 Access Control List 

This area is reserved for future use by DEC. 


3.5.6 Reserved Area 

The reserved area of the file header starts at the word 
indicated by the byte H.RSOF. This area is not used by standard 
Files -11 file managers, but is avai IabIe for use by CSS and specia I 
appIications. 
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I File Header Checksum I H.CKSM 

+-+-+ 


4.0 Directories 


Files-11 provides directories to allow the organization of files 
in a meaningful way. While the File ID is sufficient to locate a 
file uniquely on a volume set, it is hardly mnemonic. Directories 
are files whose sole function is to associate file name strings with 
File IDs. 


4.1 Directory Hierarchies 


Since directories are files with no special attributes, 
directories may list files that are in turn directories. Thus, the 
user may construct directory hierarchies of arbitrary depth and 
complexity to structure his files as he pleases. 


4.1.1 Two Level Directory Hierarchy 

Implementations of Files-11 on PDP-11 systems all support a 
two-1 eve I directory hierarchy which is tied in with the user 
identification mechanism of the operating system. Each UIC known to 
the system is associated with a user file directory (UFD) . 
References to files that do not specify a directory are generally 
defaulted to the UFD associated with the user's UIC. 

The syntax used to refer to UlCs is the same as that used to 
identify the directory in a file name string. The construct "[g,m]” 
refers to group number g, merhber number n. All UFDs are listed in 
the volume's master file directory (MFD) under a file name 
constructed from the directory string. A string of N [g,m]" 
associates with a directory name of ''gggrrrrm.DI R; 1" , where ggg and rrrrm 
are g and m padded to three characters with leading zeroes. Note 
that all number conversions are done in octal. 

Two points should be noted here. The UFD structure described 


here is not intrinsically part of the Files-11 structure; rather, it 
is a convenient cataloging system applied by the operating system. 
Also, there is no hard and fast relationship between the owner UIC of 
a file and the UFD in which it is listed. Generally they do 
correspond, but not necessarily. 


4.1.2 Multi-Level Directory Hierarchy 

New implementations of Files-11 use a multi-level directory 
hierarchy. In this scheme, the first level below the MFD is referred 
to as the user file directory (UFD) and subsequent levels are 
referred to as sub-file directories (SFDs). Users are identified at 
the command level by ASCII names; the system translates user names 
into UlCs internally. Thus, MFD entries correspond to ASCII user 
names . 

A directory specifier has the format "[name 1.name2.name3 ...]". 
Each name in the list translates to a directory file name of the form 
"name.DIR;1" and is searched for in the current directory level. 

Observe that the directory protocol is not tied to the structure 
level of the disk. Thus, new systems must always handle the H [g,m]" 
protocol, which maps to a UFD name of " gggrrrrm. D I R ; 1 " and provides 
only two levels of directory. Old systems may not be able to handle 
volumes written with multi-level directories. 


4.1.3 Mu Iti-Vo Iume Directory Structure 

In a volume set, the MFD for all user files on the volume set is 
the MFD of relative volume 1. Its entries can point to UFDs located 
on any volume in the set, the entries of which in turn may point to 
files and subdirectories on any volume in the set. The MFDs of 
remaining volumes in the set list only the reserved files on each 
vo I ume . 

The assignment of volumes to specific directories and files is 
not covered by this specification. Different systems may implement 
different policies to trade off factors such as performance, 
reliability and separability. Optimizing for performance, for 
example, usually means scattering the files as randomly as possible 
across the volume set to make the most use of the available multiple 
positioners. Maximum separability (the ability to make use of only 
part of the volume set) is achieved by locating files on the same 
volumes as their directories, and possibly by entering the 
directories in the MFDs of the volumes on which they reside. 
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4.2 Directory Structure 


F I ags 


A directory is a contiguous file, organized as a sequential file 
with variable length records, with the attribute set that records do 
not cross block boundaries, and no carriage control attributes. 

Directory entries within each block are packed together to 
conform to the variable length record format; a -1 byte count 
signals the end of records for that block. 

The entries in a directory are sorted alphabetically, permitting 
the use of an optimized search. Entries which are multiple versions 
of the same name and type are arranged in order of decreasing version 
number to optimize version related operations. 

Each directory record consists of the following: Name 


+-■ 

1 

H- 

Record Byte Count 


1 

-I- 

Version Limi t 


1 

H- 

Name Byte Count 1 Flags 


1 

+ - 

| 

-+- 

_ 

/ 

| 

File Name String 


+ - 

| 

-+- 

- 

H- 



1 

+ - 

| 

-+- 


/ 

| 

Value Field 


+ - 

| 

-+- 

- 

+ — 




Va I ue 


Count This two-byte field is the standard byte count field of a 
variable length record. 

Limit This word contains the maximum number of versions to be 
retained for this name and type. An attempt to enter more 
versions than the limit results in deletion of the least 
recent version or an error return, at the implementing 
system's opt ion. 
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This byte contains the type code of the directory entry and 
assorted flag bits. The type code is contained in the three 
low bits of the flags byte. It is one of the foilowi ng 
vaIues: 

DV.FID The value field is a list of version numbers and 
48-bit File IDs. 

The following flag bits are defined: 

DF.PRV Set if the preceding directory record contains the 
same name and type as this one. 

DF.NXV Set if the next directory record contains the same 
name and type as this one. 

This field contains the file name and type in ASCII, 
separated by a dot. The dot is present even if name, type, 
or both are null. Only upper case alphabetic and numeric 
characters may be present in the name and type. If the 
length of the name is odd, it is padded with a single null. 

This field contains the ''value" of the directory entry; 
i.e., the information returned to the user from a lookup 
operation. If the directory record is a File ID list (type 
field is DV.FID), the value field is a list of version 
numbers and corresponding File IDs, appearing in descending 
order by version number. The number of entries in the list 
is deduced from the record byte count. 


Version Number 

- + - 


-+- 

File ID 
-+- 


- + - 

Version Number 

- + - 


-+- 

File ID 
-+- 


+ 
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+ 
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I 

-+ 


RSX-41 















Version Number 



-+- 


- 

File ID 

-+- 

- 


-+- 



Version 


This word contains the version 
in binary. Version numbers 
32767. 


number of the directory entry 
must Iie in the range 1 to 


File ID 


These three words are the Fi le ID that the directory entry 
points to. 


5.0 Reserved Files 


Clearly, any file system must maintain some data structure on 
the medium which is used to control the file organization. In 
Files-11 these data are kept in several files. These files are 
created when a new volume is initial i zed. They are unique in that 
their File IDs are known constants. Note, however, that the relative 
volume number used when accessing one of these files depends upon the 
context. 

The exact number of these files which are present on a 
particular volume may vary; however, at least five must be present. 
All of these files are non-deIetab Ie . These files have the following 
uses : 


File ID 1,1 is the index file. The index file is the root of 
the entire Files-11 structure. It contains the volume's bootstrap 
block and the home block, which is used to identify the volume and 
locate the rest of the file structure. The index file also contains 
all of the file headers for the volume, and a bitmap to control the 
allocation of file headers. 

File ID 2,2 is the storage bitmap file. It is used to control 
the allocation of logical blocks on the volume. 

File ID 3,3 is the bad block file. It is a file containing all 
of the known bad blocks on the volume. 

File ID 4,4 is the vol ume master file directory, or MFD. I t 
forms the root of the volume's directory structure. The MFD lists 
the five known files, all first level user directories, and whatever 
other files the user chooses to enter. 


File ID 5,5 is the system core image file. Its use is operating 
system dependent; its basic purpose is to provide a file of known 
File ID for the use of the operating system. 

File ID 6,6 is the vol ume set list file. If this volume is 
relative volume one of a tightly coupled volume set, this file 
contains a list of the labels of all volumes in the set. 

File ID 7,7 is the standard continuation file. If this volume 
is part of a loosely coupled volume set, this file contains the first 
segment of the portion of the multi-volume file that resides on this 
vo I ume . 

File ID 8,8 is the backup journal file. This file is used to 
log and control the use of an incremental backup system. 

File ID 9,9 is the pending bad block log file. This file 
contains a list of suspected bad blocks on the volume that have not 
yet been turned over to the bad block file. 

More File IDs may be reserved in the future; users should not 
make any assumptions about the values of user created File IDs. 


5.1 Index File 


The index fiIe is FiIe ID 1,1. It is listed in the MFD as 
INDEXF.SYS;1. The index file is the root of the Files-11 structure 
in that it provides the means for identification and initial access 
to a Files-11 volume, and contains the access data for all files on 
the volume, including itself. 

This file has the FCS record format of 512-byte fixed length 
records without carriage control. 


5.1.1 Bootstrap Block 

Virtual block 1 of the index file is the volume's boot block. 
It is almost always mapped to logical block 0 of the volume. If the 
volume is the system device of an operating system, the boot block 
contains an operating system dependent program which reads the 
operating system into memory when the boot block is read and executed 
by a machine's hardware bootstrap. If the volume is not a system 
device, the boot block contains a small program that outputs a 
message on the system console to inform the operator to that effect. 

If block 0 of a volume is bad, it is permissible to map virtual 
block 1 of the index file to some other block. In this case, 
obviously, the volume cannot be used as a system volume. 
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5.1.2 Home Block 

Virtual block 2 of the index file is the volume’s home block. 
The purpose of the home block is to identify the volume as Files-11, 
establish the specific identity of the volume, and serve as the 
ground zero entry point into the volume's file structure. The home 
block is recognized as a home block by the presence of checksums in 
known places and by the presence of predictable values in certain 
Iocations. 

The home block is located on the first good block of the home 
block search sequence. The search sequence is of the form 

1 + (n * delta), where n=0, 1, 2, 3 ... 

The home block search delta is computed from the geometry of the 
volume such that, if the volume is viewed as a three-dimensional 
space, the search sequence travels approximately down the diagonal of 
the space. Since volume failures tend to occur across one dimension, 
this minimizes the chance of a single failure destroying both home 
blocks of the volume. 


The search delta is computed from the volume geometry expressed 
in sectors, tracks (surfaces) and cylinders according to the 
foilowi ng ruIes. 


Geometry 
s * 1 * 1 

1 * t * 1 

1 * 1 * c 

s * t * 1 

S * 1 * c 

1 * t * c 

s * t * c 


Delta 

1 

1 

1 

s + 1 
s + 1 
t+1 

(t+1)*s + 1 


In most cases, the home block is located on LBN 1. 


5.1.3 Cluster Filler 

If v, the cluster factor of the volume, is greater than 1, the 
next (v* 2) -2 blocks of the index file are copies of the home block 
used to fill out the first two clusters of the index file. Note 
that, for cluster factors greater than 1, this results in a wasted 
disk cluster. The benefit of this technique is a much simpler rule 
for finding the VBN of interesting parts of the index file. 


5.1.4 Backup Home Block 

The backup home block is a second copy of the home block located 
farther down the home block search sequence. It permits use of the 
volume even if the primary home block is destroyed. 

In general, the backup home block should be allocated on the 
second good block of the search sequence. If it is not, then alI 
preceding blocks on the sequence must not be available for 
allocation. This prevents the situation of a malicious user 
constructing a counterfeit index file, which would be used if the 
primary home block ever went bad. 

The cluster which contains the backup home block is mapped into 
the index file as virtual blocks (v*2)+1 through (v*3), where v is 
the volume cluster factor. Observe that the backup home block may be 
located anywhere within this cluster, because there is no hard and 
fast relationship between the cluster factor and the volume's track 
and cylinder boundaries. The entire cluster is therefore filled out 
with copies of the home block. 


5.1.5 Backup Index File Header 

The next cluster of the index file contains a backup copy of the 
index file header, so that data on the volume can be recovered if the 
index file header goes bad. The cluster occupies virtual blocks 
(v*3)+1 through (v*4), where v is the volume cluster factor. 

The LBN of the backup index file header is stored in location 
H.IHLB in the home block. The backup index file header occupies the 
first block of this cluster; the remaining blocks are not used and 
their contents are undefined. 


5.1.6 Index File Bitmap 

The index file bitmap is used to control the allocation of file 
numbers (and hence file headers). It is simply a bit string of 
length n, where n is the maximum number of files permitted on the 
volume (contained in offset H.FMAX in the home block). The bitmap 
spans as many blocks as are necessary to hold it, i.e., maximum 
number of files divided by 4096 and rounded up. The number of blocks 
in the bitmap is contained in offset H.IBSZ of the home block. 

The bits in the index file bitmap are numbered sequentially from 
0 to (n — 1 ) in the obvious manner, i.e., from right to left in each 
byte, and in order of increasing byte address. Bit j is used to 
represent file number (j+1): If the bit is 1, then that file is in 
use; if the bit is 0, then that file number is not in use and may be 
assigned to a newly created file. 
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The index file bitmap starts at virtual block (v*4)+1 of the 
index file and continues through VBN (v*4)+m, where m is the number 
of blocks in the bitmap, and v is the storage map cluster factor. It 
is located at the logical block indicated by offset H.IBLB in the 
home bIock. 


5.1.7 File Headers 

The rest of the index file contains all the file headers for the 
volume. The first 16 file headers (for file numbers 1 through 16) 
are logically contiguous with the index file bi tmap to facilitate 
their location; the rest may be al located wherever the f i le system 
sees fit. Thus, the first 16 file headers may be located from the 
data in the home block (H.IBSZ and H.IBLB) while the rest must be 
located through the mapping data in the index f i le header. 

The file header for file number n is located at virtual block 
(v*4)4m+n, where m is the number of blocks in the index file bi tmap, 
and v is the storage map cluster factor. 

The FCS end-of-f i I e mar k for the index file is located at the 
last file header ever used. All header blocks located before the EOF 
are subject to validation when used to create a new file. 

If the block contains garbage, the new header is assigned a file 
sequence number of 1, being the first use of the header block. If 
the block contains a deleted file header, the new header is assigned 
a sequence number one higher than that contained in the block. A 
block containing a valid file header must never be used to create a 
new file, even if it is marked free in the index file bi tmap. This 
prevents files from being lost if bits are dropped in the bitmap. 

Index file blocks beyond the EOF are assumed to contain garbage, 
for the purpose of creating new file headers. 


5.1.8 Index File Layout 

The following is a sketch of the blocks in the index file. 
Observe that this illustration assumes a storage map cluster factor 
greater than 2. 
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5.1.9 Home Block Details 

The following is a detailed description of the home block. Note 
that all copies of the volume's home block contain the same data, 
with the exception of the cells containing the block's VBN and LBN. 

I terns contained in the home block are identified by symbolic 
offsets in the same manner as items in the file header. The symbols 
may be defined in assembly language programs by calling and invoking 
the macro HMBL2$ , which may be found in the macro l ibrary of any 
system that supports Files-11. Alternatively, one may find the macro 
in the file FI1MAC.MAC. 


5.1.9.1 H.HBLB 4 bytes Home Block LBN 

This doubleword contains the logical block number of this 
particular copy of the home block. 


5.1.9.2 H.AHLB 4 bytes Alternate Home Block LBN 

This doubleword contains the LBN of the volume's secondary 
home block. One may determine, when scanning the home block 
sequence, whether the block read is the primary or secondary 
home block by comparing H.HBLB and H.AHLB. This value must 
be nonzero for a valid home block. 


5.1.9.3 H.IHLB 4 bytes Backup Index File Header LBN 

This doubleword contains the LBN on which the backup index 
file header is located. This value must be nonzero for a 
valid home bIock. 


5.1.9.4 H.VLEV 2 bytes Volume Structure Level 

The volume structure level and version are used to identify 
different versions of Files-11 as they affect the structure 
of all parts of the volume except the file header. This 
permits upward compatibiIity of file structures as Files-11 
evolves, in that the structure level word identifies the 
version of Files-11 that created this particular volume. 

This document describes structure level 2 of Files-11. The 
high byte of H.VLEV must contain 2. The low byte contains 
the version number, which must be greater than or equal to 
1. The version number is incremented when compatible 
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additions are made to the Files-11 structure that may be 
safely ignored by an old version of the file system. This 
document describes version 1 of structure level 2. 


5.1.9.5 H.SBCL 2 bytes Storage Bitmap Cluster Factor 

This word contains the cluster factor used in the storage 
bitmap file. The cluster factor is the number of blocks 
represented by each bit in the storage bitmap. This value 
is also referred to as the volume cluster factor. 


5.1.9.6 H.HBVB 2 bytes Home Block VBN 

This word contains the virtual block number that the cluster 
containing the copy of the home block occupies in the index 
file. This value must be nonzero for a valid home block. 


5.1.9.7 H.AHVB 2 bytes Backup Home Block VBN 

This word contains the virtual block number that the cluster 
containing the secondary home block occupies in the index 
file. The content of this word is (v*2)+1, where v is the 
storage map cluster factor. 


5.1.9.8 H.IHVB 2 bytes Backup Index File Header VBN 

This word contains the virtual block number that the backup 
index file header occupies in the index file. The content 
of this word is (v*3)+1, where v is the storage map cluster 
factor. 


5.1.9.9 H.IBVB 2 bytes Index File Bitmap VBN 

This word contains the starting virtual block number of the 
index file bitmap. The content of this word is (v*4)+1, 
where v is the storage map cluster factor. 
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5.1.9.10 H.IBLB 4 bytes Index File Bitmap LBN 


5.1.9.14 H.DVTY 2 bytes Disk Device Type 


This doubleword contains the starting logical block address 
of the index file bitmap. Once the home block of a volume 
has been found, it is this value that provides access to the 
rest of the index file and to the volume. This value must 
be non-zero for a valid home block. 


5.1.9.11 H.FMAX 4 bytes Maximum Number of Files 

This doubleword contains the maximum number of files that 
may be present on the volume at any time. This value must 
be greater than the contents of H.RSVF for the home block to 
be valid. 

If the maximum number of f i les is less than 65,536, 
then the third word of File IDs referencing files on this 
volume is simply the relative volume number, and the volume 
set of which this volume is a member may contain up to 
65,535 volumes. 

If the maximum number of files is greater than or equal 
to 65,536, then the high byte of the third word of Fi le IDs 
is the high byte of the file number, and the volume set may 
consist of up to 255 volumes. Under no circumstances may 
the maximum number of files be greater than (2**24)-1. 


5.1.9.12 H.IBSZ 2 bytes Index File Bitmap Size 

This 16-bit word contains the number of blocks that make up 
the index file bitmap. This value must be non-zero for a 
valid home bIock. 


5.1.9.13 H.RSVF 2 bytes Number of Reserved Files 

This word contains the number of reserved f i les on the 
volume. The file sequence number of each reserved file is 
always equal to its file number. Reserved files may not be 
deleted. This word must contain a minimum value of 5 to be 
vaI id. 


This word is an index identifying the type of disk that 
contains this volume. It is currently not used and always 
con ta ins 0. 


5.1.9.15 H.RVN 2 bytes Relative Volume Number 

This word contains the relative volume number that this 
volume is assigned in a volume set. If the volume is not 
part of a volume set, this word contains zero. 


5.1.9.16 H.NVOL 2 bytes Number of Volumes 

This word contains the total number of volumes in this 
volume set if the contents of H.RVN is 1 (i.e., if this 
volume is the first volume of the set). Otherwise, this 
word contains zero. 


5.1.9.17 H.VCHA 2 bytes Volume Characteristics 

This word contains bits which provide additional control 

over access to the volume. The following bits are defined: 

CH.NDC Set if device control functions are not permitted on 
this volume. Device control functions are those 
which can threaten the integrity of the volume, such 
as direct reading and writing of logical blocks, 
et c . 

CH.NAT Set if the volume may not be attached, i.e., 
reserved for exclusive use by one task or user. 

CH.RCK Set if the volume is to be read checked. All block 
reads done on this volume, for both data and file 
structure, are performed with a read, read-compare 
to insure data integrity. 

CH.W3K Set if the volume is to be wr i te checked. All block 
writes done on this volume, for both data and fi le 
structure, are performed with a write, read-compare 
to insure data integrity. 
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5.1.9.18 H.VCWN 4 bytes Volume Owner UiC 


5.1.9.24 H.VDAT 8 bytes Volume Creation Date 


5.1.9.19 


5.1.9.20 


5.1.9.21 


5.1.9.22 

5.1.9.23 


This word contains the binary UIC of the owner of the 
volume. The format is the same as that of the file owner 
UIC stored in the file header. 


This area contains the date and time that the volume was 
initialized. It is in the same binary format as that used 
in the file header. 


4 bytes Unused 5.1.9.25 


H.VPRO 2 bytes Volume Protection Code 


H.WISZ 1 byte Default Window Size 

This word contains the number of retrieval pointers used for 
the "window" (in-memory file access data) when files are 
accessed on the volume, if not otherwise specified by the 
accessor. 


This word contains the protection code for the entire 
volume. All operations on all files on the volume must pass 
both the volume and the file protection check to be 
permitted. Accessors of the volume are categorized into 
system, owner, group and world with respect to the volume 
owner UIC in the same manner as for file protection. Each 
category is controlled by a four bit field. The four access 
modes are bit encoded as follows: 

VP.RDV Deny reading files 
VP .W?V Deny writing existing files 
VP.CRE Deny creating files 
VP.DEL Deny deleting files 


H.DFPR 2 bytes Default File Protection 


5.1.9.26 H.LRUC 1 byte Directory Pre-Access Limit 

This byte contains a count of the number of directories to 
be stored in the file system's directory access cache. More 
generally, it is an estimate of the number of concurrent 
users of the volume, and its use may be generalized in the 
future. 


5.1.9.27 H.FIEX 2 bytes Default File Extend 

This word contains the number of blocks that are allocated 
to a file when a user extends the file and asks for the 
system default value for allocation. 


This word contains the file protection that is assigned to 
all files created on this volume if no file protection is 

specified by the user. 5.1.9.28 388 bytes Unused 


2 bytes Unused 5.1.9.29 H.SNAM 12 bytes Structure Name 

This area contains the ASCII name of the volume set to which 
this volume belongs, padded out to 12 bytes with spaces. If 
H.CHK1 2 bytes First Checksum this volume is not a member of a volume set, this area is 

fi I Ied wi t h blanks. 

This word is an additive checksum of al I entries preceding 
in the home block (i.e., all those listed above). It is 
computed by the same sort of algorithm as the file header 

checksum. 5.1.9.30 H.INDN 12 bytes Volume Name 

This area contains the volume name in ASCI I . It is padded 
out to 12 bytes with spaces. It is placed here in 
accordance with the proposed volume identification standard. 
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5.1.9.31 

H.INDO 12 bytes Volume Owner 




1 

VBN of This Block 

i 

H.HBVB 


This area contains an ASCII string identifying the owner of 
the volume. The area is padded out to 12 bytes with 
trailing spaces. It is placed here in accordance with the 

1 

Backup Home Block VBN 

i 

H.AHVB 


1 

Backup Index Header VBN 

i 

H.1HVB 






1 

Index File Bitmap VBN 

i 

H.1BVB 

5.1.9.32 

H.INDF 12 bytes Format Type 

This field contains the ASCII string "DECFILE11B" padded out 
to 12 bytes with spaces. It identifies the volume as being 
of Files-11 format, structure level 2. It is placed here in 
accordance wi th the proposed volume identification standard. 

1 

+- 

1 

Index File Bitmap LBN 
-+- 

i 

-+ 

i 

H. IBLB 
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+- 

1 

Maximum Number of Files 

-+- 
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-+ 

i 

H.FMAX 






1 

Index File Bitmap Size 

i 

H. 1BSZ 

5.1.9.33 

2 bytes Unused 




1 

Number of Reserved Files 

i 

H.RSVF 






1 

Disk Device Type 

i 

H.DVTY 

5.1.9.34 

H.CHK2 2 bytes Second Checksum 




1 

Relative Volume Number 

i 

H.RVN 


This word is the last word of the home 
an additive checksum of the preceding 
block, computed according to the same 
header checksum. 

Home Block Layout 

b1ock . 1 t 

255 words of 
algorithm as 
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t he home 
the file 
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1 

H.AHLB 


1 

First Checksum 

i 

H.CHK1 


1 

i _ -1- 

1 



1 

Volume Protection 

i 

H.VPRO 


1 LBN of Secondary Index File Header 

_ _ i _ 

1 

H.IHLB 


1 

Default File Protection 

i 

H.DFPR 


i- * 

1 

1 



1 


i 

H.VDAT 


1 Volume Structure Level 

1 

H.VLEV 


1 

Volume Creation Date 
—+ — 

i 



1 Storage Bitmap Cluster Factor 

1 

H.SBCL 


1 

_ 

i 







1 

+- 

-+- 

i 

-+ 
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H.LRUC 


H.WI SZ 




H.FIEX 

Unused 

H.SNAM 


H.INDN 


H.INDO 
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H.INDF 


+- 

1 

-+- 

-+ 

i 

+- 

-+- 

~ + 

1 

Format Type 

1 

+- 

1 

-+- 

- + 

1 

+- 

1 

-+- 

-+ 

1 

+- 

1 

-+- 

-+ 

1 

+- 

-+- 

-+ 

1 


1 Unused 

+- 

-+- 

-+ 

1 

Second Checksum 

1 H.CHK2 

+- 

-+- 

-+ 


5.2 Storage Bitmap File 


The storage bitmap file is File ID 2,2. It is listed in the MFD 
as BITMAP.SYS;1. The storage bitmap is used to control the available 
space on a unit. It consists of a storage control block which 
contains summary information about the unit, and the bitmap itself 
which lists the availability of individual blocks. 

This file has the FCS record format of 512-byte fixed length 
records, with no carriage control. The end-of-file mark is 
positioned to point to the last block used. The storage bitmap file 
must be contiguous. 


5.2.1 Storage Control Block 

Virtual block 1 of the storage bitmap is the storage control 
block. It contains summary information about the volume. Note that 
implementation of some items in the storage control block may require 
it to be written at mount and dismount. 


5.2. 1.1 C.VLEV 2 bytes Storage Map Structure Level 

This word contains the structure level of the storage 
control block. The high byte contains the value 2 to 
indicate Files-11 structure level 2. The low byte contains 
the version number, which must be greater than or equal to 
1 . 
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5.2.1.2 C.SBCL 2 bytes Storage Map Cluster Factor 

This word contains the storage map cluster factor of the 
volume. Its content is identical to the content of H.SBCL 
in the home block. It is placed here for convenience. 


5.2.1.3 C.VSIZ 4 bytes Volume Size 

This doubleword contains the volume size expressed in 
logical bIocks. 


5.2.1.4 C.BLKF 4 bytes Blocking Factor 

This doubleword contains the blocking factor of the volume, 
i.e. the number of physical blocks or sectors that make up 
one logical bIock. 


5.2.1.5 C.SECT 4 bytes Sectors per Track 

This doubleword contains the number of logical blocks in 
each track of the volume. 


5.2.1.6 C.TRAK 4 bytes Tracks per Cylinder 

This doubleword contains the number of tracks contained in 
each cylinder of the volume. 


5.2.1.7 C.CYLN 4 bytes Number of Cylinders 

This doubleword contains the number of cylinders on the 
volume. This and the preceding three quantities are present 
to assist optimized allocation of space on the volume. 


5.2.1.8 C.STAT 2 bytes Status Vtord 

This word contains the following status bits: 

CS.TRN Volume in transition. Set if the volume may be in 
an inconsistent state because it was not dismounted 
properly. A system which does write-on-replace 
caching of the storage map, for example, should set 
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this bit on mount and clear it on dismount. 


5.2.1.9 488 bytes Unused 


5.2.1.10 C.CKSM 2 bytes Block Checksum 

This word contains the block checksum. It is computed using 
the same algorithm as the file header checksum. 


Storage 

Control Block Layout 







1 

Structure Level 

1 

C.VLEV 

1 

Storage Map Cluster Factor 

1 

C.SBCL 

1 

+- 

1 

Volume Size in Blocks 

-+- 

1 

-+ 

1 

C.VSIZ 

1 

+- 

1 

-+- 

Blocking Factor 

-+- 

-+ 

1 

-+ 

1 

C.BLKF 

1 

+- 

1 

-+- 

Sectors per Track 
-+- 

1 

-+ 

1 

C. SECT 





1 

+- 

1 

Tracks per Cylinder 

-+- 

1 

-+ 

1 

C.TRAK 





1 

+- 

i 

Cylinders on Volume 
-+- 

1 

-+ 

i 

C.CYLN 

i i 
i i 
i i 

i i i i 

-+- 

Volume Status 

-+- 

-+- 

-+- 

- + — + — +— + — H 
1 1 1 1 

1 1 

1 1 

1 1 

C.STAT 

Unused 

1 

+- 

Block Checksum 

-+- 

1 

C.CKSM 
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5.2.3 Storage Bitmap 

Virtual blocks 2 through (n+1) are the storage bitmap itself. 
It is best viewed as a bit string of length m, numbered from 0 to 
(m-1), where m is the total number of allocatable clusters on the 
volume rounded up to the next integer multiple of 4096. 

Each cluster contains v logical blocks, where v is the storage 
map cluster factor (also referred to as the volume cluster factor) 
contained in home block location H.SBCL. The bits are addressed in 
the usual manner (packed right to left in sequentially numbered 
bytes). Since each virtual block holds 4096 bits, n blocks (where n 
= m/4096) are used to hold the bitmap. 

Bit j of the bitmap represents logical blocks (j*v) through 
((j*v)-1) of the volume; if the bit is set, the blocks are free; if 
clear, the blocks are allocated. Clearly, the last k bits of the map 
are always clear, where k is the difference between the true size of 
the volume and m, the length of the bitmap. 

Rounding the storage map file up to the next multiple of the 
volume cluster factor may result in unused blocks at the end of the 
file. The FCS end-of-file mark points to the last block used. 


5.3 Bad BIock File 


The bad block file is File ID 3,3. It is listed in the MFD as 
BADBLK.SYS;1. The bad block file is simply a file containing all of 
the known bad blocks on the volume. 

This file has the FCS record format of 512-byte fixed length 
records with no carriage control. The end-of-fiIe mark may be placed 
as the operating system's bad block handling strategy finds useful. 
Volume initialization should place the EOF at the end of the bad 
blocks found during initialization. At all times, the EOF should at 
least point past the bad block descriptor data described below. This 
ensures that the bad block data is preserved for future 
reinitializations of the volume. 


5.3.1 Factory Bad Block Descriptor 

On disks such as the RK07 and RM03, which have factory generated 
last track bad block data, the first several clusters of the bad 
block file should include the last track of the volume. This track 
contains redundantly recorded descriptions of the bad blocks on the 
volume as described in DEC STD 144, "Disk Standard for Recording and 
Handling Manufacturing Detected Bad Sectors". 
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5.3.2 Software Bad Block Descriptor 

On disks that do not have factory last track bad block data, the 
first cluster of the bad block file contains the bad block descriptor 
for the volume. It is always located on the last good block of the 
volume. This block may contain a listing of the bad blocks on the 
volume produced by a block scan program or diagnostic. 

The software bad block descriptor is most of a Files-11 
structure level 1 header map area. The first two bytes contain the 
constants 1 and 3, respectively. The third byte contains the number 
of words that contain data. The fourth byte contains the number of 
words avaiIabIe for bad block data. The last word of the block 
contains the usual additive checksum. The retrieval pointers are 
structure level 1 pointers as described below. 



Each retrieval pointer is four bytes in length. Byte 1 contains 
the high order bits of the 24-bit LBN. Byte 2 contains the count 
field, and bytes 3 and 4 contain the low 16 bits of the LBN. 

■4 - 1 - 1 - 

I Count I High I 

H-1- -h 

I Low order LBN I 
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5.4 Master File Directory 


The master file directory (MFD) is File ID 4,4. It is listed in 
the MFD (itself) as 000000.DIR;1. The MFD is the root of the 
volume’s directory structure. It lists the reserved files, plus 
whatever the user chooses to enter. The format of the MFD is the 
same as all directory files. The MFD contains entries for all user 
file directories. 


5.5 Core Image File 


The core image file is File ID 5,5. It is listed in the MFD as 
CORIMG.SYS;1. Its use is operating system dependent. In general, it 
provides a file of known File ID for the use of the operating system 
for use as a swap area, as a monitor overlay area, etc. 

This file has the FCS record format of 512-byte fixed length 
records with no carriage controI. The end-of-filemark is positioned 
to point to the physical end of file. 


5.6 Volume Set List 


The volume set list is File ID 6,6. It is listed in the MFD as 
VOLSET.SYS;1. It is used only on relative volume one of a tightly 
coupled volume set. It contains a list of the volume labels of the 
volumes contained in the volume set. 

The format of this file is FCS 64-byte fixed length records with 
implied carriage control. The first 12 bytes of record 1 contain the 
structure name of the volume set. The first 12 bytes of record n 
contain the volume label of relative volume (n-1). The remaining 52 
bytes of each record are reserved for future use. 


5.7 Continuation File 


The standard continuation file is File ID 7,7. It is listed in 
the MFD as CONTIN.SYS;1. It is used as the extension File ID when a 
file crosses from one volume of a loosely coupled volume set to 
another. The purpose of this reserved File ID is to a II ow a 
mu Iti-voIume file to be written sequentially with only one vol ume 
mounted at a time. 

Ordinarily, when a file is extended to another volume, the new 
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header must be created first to obtain the new File ID before the 
extension linkage in the current header can be written. The use of 
this reserved File ID allows the extension linkage to be written with 
a known constant before the next volume is even on Iine. 


5.8 Backup Log File 


The backup log file is File ID 8,8. It is listed in the MFD as 
BACKUP.SYS; 1 . This file contains a history of volume and incremental 
backups performed on the volume. The format of this file is FCS 
64-byte fixed length records. The content is undefined. 


5.9 Pending Bad Block Log File 


The pending bad block log file is File ID 9,9. It is listed in 
the MFD as BADLOG.SYS;1. This file contains a list identifying 
suspected bad blocks that are not currently contained in the volume 
bad bIock file. 

The format of this file is FCS 16-byte fixed length records. 
Each record represents one bad block, and has the following format: 



PF.RDE Set if a read error has occurred on this block. 
PF .WRE Set if a write error has occurred on this block. 
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Notes from the RT-11 World 


Notes from the RT-11 World 


Copyrights 

All copyrights in the RT-11 mini-tasker belong to the owner/submitter 
of the material, and not to the RT-11 SIG, DECUS, or Digital 
Equipment Corporation. If you have a question about any article in 
the mini-tasker, please contact the author directly - not the Editor 
- and not DECUS. However, if you have a comment or rebuttal, the 
mini-tasker is a forum for open discussion, and comments are 
encouraged. 

The RT-11 SIG DOES solicit signed articles for insertion in the 
mini-tasker, on or about bugs, features, hints, kinks, nifty things, 
etc., all about the RT-11 and/or RT-32 operating systems and their 
environments. Write it up, send it to me (with a note to rewrite if 
you wish), and I will try and get it in an upcoming issue. 


IND Programmers Toolbox 

Rally Barnard, our erstwhile "Tape Copy Generation" contact, has 
submitted two items from his "IND Programmers Toolbox". They are 
pretty much self-documentating. 


DBG—11 — A Symbolic Debugger (SD) for RT-11 

This month, I am encluding a paper that Marty Gentry and Linda Banche 
of the RT-11 Development Team submitted on DBG-11, a symbolic 
debugger (SD) for RT-11. It briefly covers pertinent features, and 
is designed to whet your appetite for more. If interested, please 
call your local DEC representative for more information (and then 
call Marty or Linda for the REAL poop). 


A Letter from a Reader 

A little while ago, Scott Harrod wrote me a letter describing VMS on 
the Micro PDP-11, which I published. Then Scott wrote the most 
eloquent letter stating that both the first letter and the second 
letter were only for me to read, and not for publication. Boy, was I 
tempted to print the second letter, too. 

Seriously, I do appreciate and encourage your writing to me, and I 
hope you also write to the people who have submitted articles to the 
mini-tasker to offer constructive comments. If you do, please send a 
copy to the mini-tasker so we may print it, and maintain an open 
forum. 


Nashville Spring Symposia 

As you read this, the Spring Symposia is history. For those who 
attended, I hope you learned a lot, told your boss, and have 
encouragement from your company to continue to attend. For those who 
did not, (and those who did), now is the time to start planning on 
attending the Fall Symposia in Anaheim, December 7-11, 1987, or the 
next Spring Symposia in Cincinnatti, May 16-20, 1988, or even the 
following Fall Symposia in Anaheim, October 17-21, 1988. 

If you were able to attend Nashville, please give some thought to 
writing up your feelings about one of the sessions you attended for 
the benefit of those who could not attend, and submitting it to the 
Mini-Tasker. 


Electronic Distribution of RT-11 SIG Tape 


Site: 
Service: 
Protocol: 
Phone: 

Time zone: 
Hours: 

Data rate: 
Log-on: 
Pass-word: 


GENERAL SCIENTIFIC CORPORATION 

Binaries and index 

KERMIT and VTCOM/TRANS 

(301) 340-2776 

Eastern 

6:00 p.m. to 8:00 a.m. <- PLEASE NOTE !! 

1200 baud 

DECUS 

GUEST 


And finally, I am always looking for something of interest to print. 


Please send your submissions to the mini-tasker (on RX-50, 1600bpi 

mag tape, or pieces of paper) to me at: 


Bill Leroy (RT-11 mini-tasker) 
The Software House, Inc. 

P. 0. Box 52661 (OR) 

Atlanta, GA 30355-0661 


Bill Leroy (RT-11 mini-tasker) 
The Software House, Inc. 

2964 Peachtree Road, NW #300 
Atlanta, GA 30305-2120 
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Two items for the 


Process the file name here and add the default device. 


IND Programmers Toolbox 
by Rally Barnard 


--- PARSE.IND --- 

PARSE.IND Control file for parsing a filespec. 

PARSE is called from another control file. 

In calling file, use the following statements: 

.enable global 

.sets $DEFDV "xxxt:3" . ;You may include a " : " if not null device, 
.sets $DEFXT "C.1DSK" .;You may include "." in default extension. 

©PARSE 'INPUT' 


In PARSE, PI is 'INPUT' from the calling routine. Return is $FILSP, 
$FILNM and $DEV, where $FILSP contains the entire filespec 
(DEV:NAME.EXT) , $FILNM contains the name and extension (NAME.EXT) , 
and $DEV separately contains the device (DEV:), terminated by a : . 
If $DEFDV is null, then $DEV will return null. PARSE will return 
just the device if the input does not contain a file name. 

Written by: R. W. Barnard 

BlO/Comp Applications 
Albuquerque, NM 87185 

Version 3.5, 19-Mar-87. 

.parse PI ":" DEV FNAME 

.if <STRLEN> eq 1 .goto 10 . ;0nly 1 component was entered. 

We were supplied both a device and a file. 

Be sure we are using the physical name of the device. 

.testdevice 'DEV' 

.parse <EXSTRI> M ,” $DEV REST 

.sets $DEV $DEV+":" . ;A device was supplied. 

.goto 30 

See if we have just a device or just a file. 

.test PI .;See if only a device was given, 

.if <STRLEN> eq 0 .goto 20 . ;Just a file - no device, 

.testdevice 'DEV' 

.parse <EXSTRI> $DEV REST 

.sets $DEV $DEV+”.;0nly a device was supplied. 

.sets $FILNM "" .;Set the file name to blank and return. 

.sets $FILSP 

.exit 


.20: .sets FNAME DEV .;Device was not entered. 

.sets $DEV $DEFDV .;Use default device name. 

.if $DEFDV eq ”" .goto 30 . ;Null default device was supplied, 

.test $DEFDV ":" .;See if : was supplied. 

.if <STRLEN> eq 0 .sets $DEV $DEV+”:" 

Now see if extension was entered. 

.30: .test FNAME "." 

.if <STRLEN> eq 0 .goto 40 
.parse FNAME ".” FNAME EXT 
.if EXT ne "" .goto 50 
.sets $DEFXT “” 

.40: .test $DEFXT 

.if <STRLEN) ne 0 .parse $DEFXT 
.sets EXT $DEFXT 

.50: .sets $FILNM M 'FNAME'.'EXT'" 

.sets $FILSP "'$DEV''$FILNM'" 

* } 

. exit 


--- INDFIL.IND --- 

INDFIL.IND Control file for determining from which device 
an IND control file was run. 

This file can be made a subroutine of a larger IND file. 

It should be called first (i.e., before any other IND directives 
such as .parse, .test, etc) are done. 

This routine returns the name of the device from which it was 
run (INDDEV), the file name (INDFIL) and any switches which were 
specified (SW1, SW2, SW3, SW4). 

Written by: R. W. Barnard 

BlO/Comp Applications 
P. 0. Box 5342 
Albuquerque, NM 87185 

Version 1.1, 19-Mar-87. 

indfil: 

.sets INDEXT ".IND" .;Default extension for IND files, 

.parse P0 "/" P0 SWITCH 
.test P0 ".” 

.if <STRLEN> eq 0 .sets P0 P0+INDEXT .;Use the right extension, 
.testfile 'P0' 

.parse <FILSPC> INDDEV INDFIL 

.testdevice 'INDDEV' 

.parse <EXSTRI> "," INDDEV REST 

.parse SWITCH "/" SW1 SW2 SW3 SW4 
.return 


. ;See if . was entered. 

. ;No extension was given-use default 

. ;Extension was provided. 

.;Make the extension null. 

.;See if . was supplied. 

A $DEFXT 

. ;Use the default extension. 

.;Build the file name. 

.;Build the complete file spec. 
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DBG-11 


DBG-11 


Commands 


Operating parameters 
o [qual];R 

J3IN _OCT _HEX _DEC 

© [qual];T 

_REG or NOREG _SYM or _NOSYM 
ADR or NOADR _RUBor_NORUB 
© [qual];V 

T4 T10 TR JO 


Registers and symbols 

© Register grouping 

o PDP-11 machine registers 

o DBG-11 internal registers 

© Symbol grouping 

o PDP-11 machine register symbols 

o DBG-11 permanent symbols 

o DBG-11 internal symbols 

o User-defined symbols 


DBG-11 

Numeric/symbolic addressing 

© Octal address for locations within a program 
© Define symbol to refer to location 
© Numeric and symbolic can be combined 


Defined by colon character (:) 
o 1000,START: (1000) 

o START+174, ANSWER: (1174) 

o -<START+5>,FOO: (176773) 

O <ANSWER-START>_/2,VALUE: (000076) 


DBG-11 

Expressions 

© Can represent an absolute address, 
offset, or instruction 

© Can contain any of following elements 
o PDP-11 machine instructions 

o Numeric value 

o Symbolic value 

o Current location symbol (.) 

o Last typed address symbol (Q) 
o Binary arithmetic operators 

o Unary arithmetic operators 


DBG-11 


Components 

DBG-11 

o Pseudo-device handler 

A SYMBOLIC DEBUGGER (SD) 

o Software 

FOR RT-11 

o Hardware 

© Symbol definition utility 


DBG-11 

DBG-11 Features 

© Control program execution 

© Display in numeric or mnemonic format 

© Change contents 

o Memory locations 
o Registers 

© Define symbol names for memory addresses 


DBG-11 

Numeric values 

© Defaults to OCTAL unless 8, 9, or dot (.) 

© Independent of output radix setting 

© Prefix operators 

o _$ up to 4 hex digits follow 
o _% up to 3 RAD50 characters follow 
o 2 ASCII characters follow 
o * 1 ASCII character follows 


ii 
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DBG-11 


DBG-11 


Getting started 


Special Symbols 


5. Debug - setting breakpoints 

o Dot (.) 

6. Prompts 

o BE: 1000 

DBG> 0 Q 

o BE: (U) 1000 

DBG> DBG-11 

Advanced techniques 


o Device handlers 


Graphics register display 


Accessing memory outside program space 


073374 


ISP) 


105456 
056.213 
%VJ0 


177777 

377,377 

%??? 


'•<51 


4(SP) 


076000 072620 

000.174 220.165 


%S3X 'PU %B2P 


-013700 6(SP)-000054 


o DBGSYM 
DBG-11 


DBGSYM 


o A symbol Definition Utility 

o Uses .STB Files as input 

o Defines ail global symbols 

for use by DBG 


DBG-11 DBG-11 

Commands Using DBG-11 


© Define user symbol [addrjsymbol: 0 SD pseudo-device handlers 

o Set/remove breakpoints [addr][,n];B 


Execute program 



o SET commands 

[addr];G 

[val];P 

[val];S 

o 

SYSGEN 

Open and display 



o 

ADROFF=val 

[addr]” 

[addr]’ 

[addr]% 

o 

DATOFF=val 

[addr]/ 

[addr][ 

[addr]j 

o 

CSR=val 

[addr]\ 



o 

[NO]REG 




o 

BREAK 


DBG-11 DBG-11 

Commands Getting started 


Change contents 1. Copy appropriate file to handler name format 


[val]<RET> 

[val]<LF> 

[val]‘ [val]@ 

2. Tailor environment with SET commands 

Display expression 
Special characters 

values 

[val]= 

3. INSTALL SD 

RUBOUT 

CTRL/C 

CTRL/Q 


CTRL/S 

CTRL/U 

CTRL/W 

4. .LOAD SD 


DBG V01.14-RT-11 ( SOFT PRO SD: GRH ) 
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Editor’s Corner 


Selected from the Usenet in March 

Jim Livingston, Toolkit Editor 


This editorial will be short, since we’re in the process of preparing for the Nash¬ 
ville symposium and there’s very little time left. The unfortunate fact of life is 
that you’ll likely not get this until after said symposium, so there’s no point in 
telling you all the wonderful things to expect there. Nevertheless, I’ll do my best 
to give you, who didn’t get there, some summary of the events that might be of 
interest in the Toolkit for July. 

In any case, this issue includes a number of selections from the Usenet. I’ve al¬ 
ways thought that we might be a useful conduit for information from that source, 
since many of our subscribers have no access to the network directly. In this is¬ 
sue, we have contact information for the general UNIX community, as well as 
specific information about standards which affect the UNIX community. You 
may find those quite useful. 

In addition, you’ll notice something of an introduction to the mod.sources news- 
group of Usenet, which, for those who’re not familiar with it, is a group devoted 
to collecting public domain software for UNIX systems and making it available to 
whomever asks for it. I thought this would be a particularly good inclusion for 
those in our community who don’t yet see the value in joining the network. 

You’ll also find, courtesy of our Digital friends, a brief product description of 
VAX C for ULTR1X. There’s a sort of commercial flavor to it, I’ll agree; the 
difference between a frankly commercial product announcement and this, in my 
opinion, is that what’s being announced is free with the ULTREX 2.0 kit. I grant 
that’s a kind of pricing information, but I think you’ll agree that it’s the kind 
we’d all like to hear. I’d be interested in your feelings about information like this 
being in these pages. 

Last, I’m including a particularly good paper that was presented at the San Fran¬ 
cisco symposium. I’ve waited this long, in part, because I wanted to be sure it 
didn’t appear in the Proceedings of the symposium. Duplicate publication of pa¬ 
pers is frowned upon in the organization. In this case, however, I think that, even 
though it was in the symposium session notes, it deserves wider distribution. Let 
me know what you think about that. 


Submitted by: Rich Salz < rs(3mirror. TMC. COM> 

Mod.sources: Volume 9, Info 1 
Archive-name: index9.1 

This is the first of two introductory messages about mod.sources. This 
one describes how to submit source to mod.sources, where the archive 
sites are, and how to contact them. The companion articles lists all 
previously-published mod.sources articles. 

I am always looking for suggestions on how to improve the usefulness 
of mod.sources, and can be contacted as listed below. 

-Rich Salz 


SUBMITTING SOURCE FOR PUBLICATION 

Items intended for posting should be sent to mirror!sources; requests 
for missing copies or other queries should be sent to mirror!sources-request 
In Australia, Robert Elz is a "sub-moderator"; people there can work 
with him (kre@munnari.OZ) to get postings out more easily. 

If you want verification of arrival, so say in a cover note, or at the 
beginning of your submission, if it is small. I try to verify that a 
program works, and if I can't get it to work, I may hold up posting it 
for a couple of days. Please note that, except in rare cases, source 
without documentation and a Makefile will not be published. The backlog 
from receival to posting is now about two weeks; this will probably 
shrink down to one week in the upcoming weeks. 

When you send mail, MAKE SURE to include a return address relative to 
some well-known site(s). When all else fails, my conventional address 
and phone number are: 

Rich $alz 

Mirror Systems 

2067 Massachusetts Avenue 

Cambridge, MA 02140 

617-661-0777 


THE STRUCTURE OF MOD.SOURCES ARTICLES 

Each posting in mod.sources is called an "issue"; there are 100 issues 
to a volume. The division is arbitrary, and has varied greatly in the 
past. There are two types of articles in mod.sources; sources and 
"information postings." They can be distinguished by the subject 
line: 

Subject: V07INF8*. Index for Volume 7 and other info 
This first word in the title identifies this as the eight info posting 
in volume seven. Similarly, the subject line shown below: 

Subject: v07i081: Public-domain Unix kernel 
identifies this as the 81st source article in Volume 7. Large sources 
are broken up into smaller pieces, and have subject lines that look like 
this: 

Subject: v07i082: System VI Source Distribution, Part03/08 

The first few lines of an article are auxiliary headers that look like this: 


UNI-i 


UNI-1 







2 . 


Submitted by: root@freeware.ATT.COM 
Mod.sources: Volume 7, Issue 82 
Archive-name: new-login 

The "Submitted by" is the author of the program. If you have comments about 
the sources published in mod. sources, this is the person to contact. 

When possible, this address is in domain form, otherwise it is a UUCP bang 
path relative to site "mirror" (my machine). 

3. 

The second line repeats the volume/issue information for the aide of NOTES 
sites and automatic archiving programs. 

4. 

The Archive-name is the "official" name of this source in the archive. Large 
postings will have names that look like this: 

Archive-name: patch2/Part01 

Please try to use this name when requesting that sources be mailed to you. 

Also, note that the "part number" given in the title, and the archive name 
given in the auxiliary header need not be identical. 5. 


ACCESSING THE MOD.SOURCES ARCHIVE 

The complete mod.sources archives are fairly large: 

Volume Size (Kbytes) 

1 4004 

2 1204 

3 3434 

4 4220 6. 

5 390 

6 4220 

7 3976 

8 4416 

There are several active archive sites around the net. I am particularly 
interested in helping set up a BITNET archive. A French archive site 
is being set up, and it may be extended to provide full European coverage; 

I will post more information as soon as things are settled. 

7. 

When you request something before Volume 6, please make sure to be as 
descriptive as possible as articles before then do not have official 
names. 

Several sites below will send tapes through the mail. For those sites, 

send a 1/2" mag tape WITH-RETURN POSTAGE and RETURN MAILER. Tapes 8. 

without postage or mailer will not be returned. No other methods (COD, 

etc.) are available; please don't ask. 

Finally, please note that I am Rich $alz, rs@mirror; Rick Adams is 
rick@seismo, and Rich Kulawiec is rsk@j.cc.purdue.edu; we appreciate 
the extra effort to get our names right. :-) 

1. Phil Burdi has an archive on-line; contact usenet@cuae2.ATT.COM for more 
info. He has also set up an off-hours UUCP login providing anonymous 
UUCP access to the archives. The L.sys (Systems file) entry looks like: 

(for HoneyDanBer UUCP users) 9. 

cuaepd Wkl830-0530,Sa,Su ACU 1200 3129643773 in:—in: pduucp 
(for other UUCP users) 

cuaepd Anyl830-0530 ACU 1200 3129643773 in:—in: pduucp 
Retrieve the file cuaepd! ~/netnews/mod. sources/howto, snarf and follow the 
directions therein. 
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Pyramid Technology has an archive arranged topically, and in compressed 
tar files. They are happy to take new UUCP connections. They are also 
somewhat willing to make tapes for people to come by and pick up, 
provided you call WELL in advance and bring lunch money. This is being 
managed by Claudia Dimmers and/or Carl Gutekunst. Contact 
pyramid!Usenet for more info. 

Robert Elz (kre@munnari.OZ) keeps mod.sources in different ways 
depending on his available disk space; contact him for more info. 

Thos Sumner at UCSF will respond to requests for material, but cannot 
promise an ongoing commitment. Anyone requesting material via mail 
should supply a path from ucbvax. Anyone requesting tape should 
contact me first. Contact him at thos@cca.ucsf.edu, or 
ucbvax!ucsfcgl!cca.UCSF!thos 

Tom Patterson at Washington University can make 800/1600/6250 BPI 
tar tapes. If you give him a "real good reason," he can also make 
1600 BPI VMS BACKUP or ANSI tapes. Send your tape, mailer, and postage 
to Tom at: 

Engineering Computer Lab, Bryan 509 
Lindell & Skinker Blvd 
Washington University 
St. Louis, MO 63130 

For best results, first send mail to wucs!archive (you stand a better 
chance of getting processed quickly that way). 

Jim Thompson (ottoljim) can make 1600 and 6250 tar and cpio tapes, 
as well as VMS backup in a real pinch. He will also provide a 
temporary UUCP login for interested parties at 1200 or 2400 baud. 

His postal address is: 

Jim Thompson 
c/o Sun Teleguide 
2551 Green Valley Pkwy 
Henderson, Nv. 89015 
(702) 454-4636 

Of course, I have a complete set of archives. I can mail individual 
postings, make files available for UUCP, and will send tapes (1600 
BPI tar; 6250 or cpio in a crunch). Last time I checked, it cost 
about $3 to send a 2400' tape across the country in a padded envelope 
via first-class mail. 

Rick Adams (rick@seismo.CSS.GOV) provides archive access to those on the 
Internet. Access is available directly via anonymous FTP (Outside of 
9am-7pm EST M~F.) The files are in a directory mod.sources, then a 
sub-directory Volume[1-7], They are named as closely as possible to the 
names in the Index. Files that have not been assigned a "short name" 
reside in the directory sources/mod temporarily. Send tape, mailer, 
and postage to Rick at: 

Center for Seismic Studies 

1300 North 17th Street, Suite 1450 

Arlington, VA 22209-3871 

Internet sites may also retrieve archives from j.cc.purdue.edu via 
anonymous ftp. The archive is in the directory "mod.sources", 
subdivided into "volumel", etc. Due to disk space considerations, 
many of the sources are compressed; these may be recognized by the 
".Z" suffix. If you don't have compress & friends, they are in 
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~ ftp/pub/comp res s. shar for the taking. This is being managed by 
Rich Kulawiec (Wombat), pucc-j!rsk, rsk(5j .cc.purdue.edu. If your 
host tables don't grok "j.cc.purdue.edu", try "purdue-asc.arpa". 

They would appreciate it if you would avoid large file transfers 
in the middle of the day. [Rick also points out that the FTP' able 
archies also contain mod.amiga, a bunch of kermit sources, news 
2.11, rn 4.3, nntp, and whatever else happens to be in ~ftp/pub at 
the moment.] 

10. The CSNET CIC has been doing a fair amount of work to bring their 
automated retrieval up-to-speed. They now have a complete archive, 
and are making things available as quickly as possible (they have 
special legal restrictions on what they can distribute, so everything 
may not be available). Look in the latest issue of the CSNET Forum, 
or contact postmaster(2sh.cs.net. 


VAX C/ULTRIX! 


PRODUCT SUMMARY 

VAX C for ULTRIX Systems is a port of the VAX C V2.3 product for VMS 
systems to the ULTRIX-32 operating system run time environment. It is 
an implementation of the C programming language as described by 
Kernighan and Ritchie in "The C Programming Language" with some 
extensions as defined by the proposed ANSI standard for C. 

FEATURES 

o VAX C/ULTRIX is a highly optimizing compiler for the C 

programming language. Many compute-bound C applications will 
run 1.2 to 2 times faster than when compiled with the Portable 
C Compiler (PCC) native on ULTRIX-32. Improvement to a lesser 
degree may result for programs manually optimized for PCC by 
experienced UNIX programmers who use workarounds to avoid the 
limitations of PCC. 

o A major goal of the product was to integrate VAX C into the 

ULTRIX-32 environment such that it can be used in place of PCC 
whenever possible. VAX C/ULTRIX: 

supports the PCC command line with the exception of the 
following options: -go, -p, -t, -R, -S, -B. Additional 
command line options will be provided to support VAX C 
extensions. 

will use the native run time and system libraries on 
ULTRIX-32. It will also use the native header files (such 
as stdio.h) and the dbx debugger. 

VAX C/ULTRIX cannot be used for system level programs 
requiring the ASM pseudo function or where undocumented or 
non-standard C features of PCC are used. If necessary, an 
application can be linked using some object modules 
compiled with VAX C and others compiled with PCC when the 
DEC-developed LK linker is used. 


permits data objects to be aligned on arbitrary 
boundaries, such as longword or page. VAX C/ULTRIX will 
support this form of aggregate padding and alignment under 
command line control. This option will also be added to 
VAX C under VMS. The default for the command line option 
such that both systems will get the expected behaviour 
without specifying any command line options. 

has been enhanced such that the preprocessor supports the 
elif and if defined directives. 

provides a full listing of the source code, including 
expanded preprocessor substitutions, generated machine 
code, included header files and symbol cross references, 
each under command line control. 

can insert calls to profiling routines during compilation 
so that execution profiling can be done at execution time, 
as does PCC. 


o VAX C/ULTRIX is source code compatible with VAX C V2.3 for 
VMS systems, except for VMS specific extensions such as 
support for RMS, LSE, SCA, CDD, and VMS system calls. 

o VAX C/ULTRIX supports the "const" and "volatile" keywords, and 
function prototypes as defined in the proposed ANSI standard 
X3J11 for C. Finalization of this standard is expected in 
late 1987 or early 1988. 

o The PCC compiler supports a command line option to specify 
alternate search paths for named include files. Both VAX C 
V2.3 and VAX C/ULTRIX VI. 0 will support a command line switch 
to specify a list of directories to be searched for include 
files. The command line option for VAX C/ULTRIX will the same 
as that for the PCC compiler. 

The C programming language is considered an integral part of a UNIX 
operating system environment and not merely an optional language 
compiler. This is one of the major reasons that VAX C/ULTRIX, unlike 
VAX FORTRAN for the ULTRIX Operating System, is packaged with the 
ULTRIX-32 operating system. 

It is also for this reason that VAX C/ULTRIX is engineered to work in 
the same manner as PCC so that it can be used to compile C programs on 
ULTRIX-32 with few or no source code changes. Also, in keeping with 
the ULTRIX-32 strategy of driving and supporting industry standards, 

VAX C/ULTRIX has begun to incorporate features of the draft ANSI C 
standard which is expected to be finalized sometime within the next 
year. Another goal was that it remain compatible with VAX C V2.3 on 
VMS systems to provide portability between the two operating systems. 

VAX C/ULTRIX should be used for applications development in order to 
take advantage of the performance gain expected by its use. PCC is 
still required for system level code requiring the ASM pseudo function 
or where, undocumented or non-standard C features of PCC are used. 
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SOFTWARE REQUIREMENTS 


Selected from the Usenet in March 
(Thanks to Kathy Hornbach of DEC) 


VAX C/ULTRIX will be packaged with ULTRIX-32 Version 2.0. VAX C/ULTRIX 
will not run on earlier versions of the ULTRIX-32 operating system nor 
on any other operating system but ULTRIX-32. 

HARDWARE REQUIREMENTS 


VAX C/ULTRIX supports all VAX, MicroVAX and VAXstation processors 
supported by ULTRIX-32 Version 2.0. 

ORDERING INFORMATION 


Since VAX C/ULTRIX will be packaged with Version 2.0 of ULTRIX-32 it is 
not sold or priced separately. Media and documentation for VAX 
C/ULTRIX will be received when the ULTRIX-32 V2.0 H-kit is ordered. 

AVAILABILITY 


VAX C/ULTRIX is expected to be available from the U. S. Software 
Distribution Center with ULTRIX-32 Version 2.0 in May, 1987. 

* UNIX is a registered trademark of AT&T Bell Laboratories 


This is the latest in a series of similar mod.std.unix articles. 
Corrections and additions to this article are solicited. 


Access information is given in this article for the following 
standards: 

IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification) 
/usr/group working groups on distributed file system, network, 
interface, graphics/windows, database, 

internationalization, performance measurements, realtime, 
and security 

X3H3.6 (display committee) 

X3J11 (C language) 

/usr/group Standard 

System V Interface Definition (SVID, or The Purple Book) 

X/OPEN PORTABILITY GUIDE (The Green Book) 


UNIX is a Registered Trademark of AT&T. 

POSIX and IEEE are trademarks of the Institute of Electrical 
and Electronic Engineers, Inc. 

X/OPEN is a licensed trademark of the X/OPEN Group Members. 


The IEEE P1003 Portable Operating System for Computer Environments 
Committee is sometimes known colloquially as the UNIX Standards 
Committee. They have published the 1003.1 "POSIX” Trial Use Standard 
in April 1986. According to its Foreword: 

The purpose of this document is to define a standard operating 
system interface and environment based on the UNIX Operating 
System documentation to support application portability at the 
source level. This is intended for systems implementors and 
applications software developers. 

Published copies are available at $19.95, with bulk purchasing 
discounts available. Call the IEEE Computer Society in Los Angeles 

714-821-8380 

and ask for Book #967. Or contact: 

IEEE Service Center 445 Hoes Ln. Piscataway, NJ 08854 

and ask for "IEEE 1003.1 Trial Use Standard” - stock number SH10546. 

The Trial Use Standard will be available for comments for a period such 
as a year. The current target for a Full Use Standard is Fall 1987. 
IEEE has initiated the process to have the 1003.1 effort brought into 
the International Organization for Standardization (ISO) arena. 

Machine readable copies of the Trial Use Standard are not and will not 
be available. A machine-readable "representation” of a draft between 
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the Trial Use and Full Use Standards may be available when it is ready 
(probably in 1987). 

There is a paper mailing list by which interested parties may get 
copies of drafts of the standard. To get on it, or to submit comments 
directly to the committee, mail to: 

James Isaak Chairperson, IEEE/CS P1003 Digital 
Equipment MK02-2/B05 Continental Blvd. 

Merrimack, NH 03054-0403 decvaxljim 603-884-3692 

Sufficiently interested parties may join the working group. 

Related working groups are 

group subject co-chairs 1003.2 shell and tools Hal 

Jespersen (Amdahl), Don Cragun (Sun) 1003.3 verification 
Roger Martin (NBS), Carol Raye (AT&T) 

Inquiries regarding 1003.2 and 1003.3 should go to the same address as 
for 1003.1. 


The next scheduled meetings of the P1003 working groups are, in 1987: 


April 

April 

June 

June 


20-21 1003.[23] King Edward Hotel, Toronto Host: IBM 

22-24 1003.1 

(Just before the Canadian UNIX Conference) 

22-23 1003.1 Seattle (changed from USENIX week in Phoenix to 

give us better 'working' attendance) No Host yet 
24-26 1003.[23] 


Aug/Sept 31-4 East Coast Probably Washington DC area No Host yet 
OR Sept .14-18 Boston (Same Time/loc as X3J11) 

(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash 
DC) 


There is also a balloting group (which intersects with the working 
group). This is more difficult. Contact the committee chair for 
details. I will repost them in this newsgroup if there is sufficient 
interest. 


Here are some details from Hal Jespersen regarding P1003.2: 

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a 
proposed standard to complement the 1003.1 POSIX standard. It will 
consist of 


a shell command language (currently planned to be based on the 
Bourne Shell), 

groups of utility programs, or commands, 

programmatic interfaces to the shell (system(), popen()) and 
related facilities (regular expressions, file name expansion, 
etc.) 

defined environments (variables, file hierarchies, etc) that 


applications may rely upon 

which will allow application programs to be developed out of existing 
pieces, in the UNIX tradition. The scope of the standard emphasizes 
commands and features that are more typically used by shell scripts or 
C language programs than those that are oriented to the terminal user 
with windows, mice, visual shells, and so forth. 

The group is currently seeking proposals for groupings of commands that 
may be offered by implementors. As groups are identified, command 
descriptions will be solicited. There is no requirement that the 
commands be in System V or BSD today, but they should realistically be 
commands that are commonly found in most existing implementations. 

Meetings are normally held in conjunction with the 1003.1 group and 
have a large membership overlap. Future meetings will generally be 
held on the day or two preceding 1003.1. 


There are three Institutional Representatives to P1003: John Quarterman 
from USENIX, Heinz Lycklama from /usr/group, and John Loman from X/OPEN. 

As the one from USENIX, one of my functions is to get comments from the 
USENIX membership and the general public to the committee. One of the 
ways I try to do that is by moderating this newsgroup (currently known 
as mod.std.unix, very soon as comp.std.unix). An article related to 
this one appeared in the September/October 1986 /login: (The USENIX 
Association Newsletter). I'm also currently on the USENIX Board of 
Directors. Comments, suggestions, etc., may be sent to 

John S. Quarterman 
TIC 

P.0. Box 14621 
Austin TX 78761 
512-837-7233 
usenix!jsq 

For mod.std.unix (comp.std.unix): 

Comments: ut-sally!std-unix-request std-unix-request@sally.utexas.edu 

Submissions: ut-sally!std-unix std-unix@sally.utexas.edu 

The January/February 1987 issue of CommUNIXations (the /usr/group newsletter) 
contains a report by Heinz Lycklama on the /usr/group Technical Committee 
working groups which met in September 1986. 

If you are interested in starting another working group, contact 
Heinz Lycklama: 


Heinz Lycklama 
Interactive Systems Corp. 

2401 Colorado Ave., 3rd Floor 
Santa Monica, CA 90404 
(213)453-8649 
decvax!cca!ima!heinz 


Here is contact information for /usr/group working groups as taken from 
the CommUNIXations article mentioned above. 
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/usr/group Working Group on Distributed File System: 
Dave Buck 

D.L. Buck & Associates, Inc. 

6920 Santa Teresa Bldg, #108 
San Jose, CA 95119 
(408)972-2825 


is not based directly on any existing system. The chair solicits 
help and participation: 

Georges Grinstein 
wanginst!ulowell!grinstein 


/usr/group Working Group on Network Interface: 

Gil McGrath 

AT&T Information Systems 
(201)522-6182 

/usr/group Working Group on Internationalization: 
Karen Barnes 
Hewlett-Packard Co. 

19447 Pruneridge Ave. 

M/S 47U2 

Cupertino, CA 95014 
(408) 725-8111, ext 2438 

/usr/group Working Group on Graphics/Windows: 

Tom Greene 

Apollo Computer, Inc. 

(617)256-6600 


The Abstract of the 1003.1 Trial Use Standard adds: 

This interface is a complement to the C Programming Language 
in the C Information Bulletin prepared by Technical Committee X3J11 
of the Accredited Standards Committee X3, Information Processing 
Systems, further specifying an environment for portable application 
software. 

X3J11 is sometimes known as the C Standards Committee. Their liaison to 
P1003 is 

Don Kretsch 
AT&T 

190 River Road 
Summit, NJ 07901 

A contact for information regarding publications and working groups is 


/usr/group Working Group on Realtime: 

Bill Corwin 
Intel Corp. 

5200 Elam Young Pkwy 
Hillsboro, OR 97123 
(503)681-2248 

/usr/group Working Group on Database: 

Val Skalabrin 
Unify Corp. 

1111 Howe Ave. 

Sacramento, CA 95825 
(916)920-9092 

Measurements: 

Dave Hinant 
SCI Systems, Inc. 

Ste 325, Pamlico Bldg 
Research Triangle Pk, NC 27709 
(919)549-8334 


/usr/group Working Group on Security: 
Steve Sutton 
Computer Systems Div. 

Gould Inc. 

1101 East University 
Urbana, IL 61801 
(217)359-0700 


/usr/group Working Group on Performance 
Ram Celluri 
AT&T Computer Systems 
Room E15B 
4513 Western Ave. 

Lisle, IL 60532 
(312)810-6223 


The X3H3.6 display management committee has recently formed to develop 
a model to support current and future window management systems, yet 


Thomas Plum 

Vice Chair, X3J11 Committee 
Plum Hall Inc. 

1 Spruce Avenue 
Cardiff, New Jersey 08232 

The current document may be ordered from 

Global Press 
2625 Hickory St. 

P.0. Box 2504 

Santa Anna, CA 92707-3783 

U.S.A. 

800-854-7179 

+1-714-540-9870 (from outside the U.S., ask for extension 245.) 
TELEX 692 373 

who know X3J11 as X3.159. The price is $65. 


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN, 
and possibly even X3J11: 

/usr/group Standards Committee 
4655 Old Ironsides Drive, Suite 200 
Santa Clara, California 95054 
(408)986-8840 

The price is still $15.00. 

The System V Interface Definition (The Purple Book, or SVID). 

This is the AT&T standard and is one of the most frequently-used 
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references of the IEEE 1003 committee. 

AT&T Customer Information Center 

Attn: Customer Service Representative 

P.0. Box 19901 

Indianapolis, IN 46219 

U.S.A. 

800-432-6600 (Inside U.S.A.) 

800-255-1242 (Inside Canada) 

317-352-8557 (Outside U.S.A. and Canada) 

System V Interface Definition, Issue 2 

should be ordered by the following select codes: 

Select Code: Volume: Topics: 

320-011 Volume I Base System 

Kernel Extension 

320-012 Volume II Basic Utilities Extension 

Advanced Utilities Extension 
Software Development Extension 
Administered System Extension 
Terminal Volume Interface Extension 
320-013 Volume III Base System Addendum 

Terminal Interface Extension 
Network Services Extension 
307-131 I, II, III (all three volumes) 

The price is about 37 U.S. dollars for each volume or $84 for all three. 
Major credit cards are accepted for telephone orders: mail orders 
should include a check or money order, payable to AT&T. 


The X/OPEN PORTABILITY GUIDE (The Green Book) 
is another reference frequently used by IEEE 1003. 

The X/OPEN Group is ’’Ten of the world’s major information system 
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL, 
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have 
produced a document intended to promote the writing of portable 
facilities. They closely follow both SVID and POSIX, and cite 
the /usr/group standard as contributing, but X/OPEN's books 
cover a wider area than any of those. 

The book is published by 

Elsevier Science Publishers B.V. 

Book Order Department 
P.0. Box 1991 
1000 BZ Amsterdam 
The Netherlands 

and distributed in the U.S.A. and Canada by: 

Elsevier Science Publishing Company, Inc. 

52 Vanderbilt Avenue 
New York, NY 10017 
U.S.A. 
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There are currently five volumes: 

1) System V Specification Commands and Utilities 

2) System V Specification System Calls and Libraries 

3) System V Specification Supplementary Definitions 

4) Programming Languages 

5) Data Management 

They take a large number of credit cards and other forms of payment. 


Selected from the Usenet in March 
(Thanks to Kathy Hornbach of DEC) 


This is the latest in a series of similar mod.std.unix articles. 
Corrections and additions to this article are solicited. 

The newsgroup mod.std.unix will very soon be known as comp.std.unix. 


Access information is given in this article for the following: 
user groups: USENIX, /usr/group, EUUG, AUUG, DECUS 

newsletters: ;login:, CommUNIXations, EUUG, AUUGN 

magazines: UNIX REVIEW, UNIX/WORLD 

UNIX is a Registered Trademark of AT&T. 


USENIX is "The Professional and Technical UNIX(R) Association." 

USENIX Association 
P.0. Box 7 

El Cerrito, CA 94530 
415-528-8649 

[ucbvax,decvax}!usenix!office 

USENIX sponsors two USENIX Conferences a year, featuring technical papers, 
as well as tutorials, and with vendor exhibits at the summer conferences: 

Jun 8-12 1987 Hyatt Regency, Phoenix, AZ 

Feb 10-12 1988 Registry Hotel, Dallas, TX, concurrent with Uniforu 

Jun 21-24 1988 Hilton Hotel, San Francisco, CA 

Feb 1- 3 1989 Town and Country Hotel, San Diego, CA 

Jun 13-16 1989 Hyatt Regency, Baltimore, MD 

Jun 11-15 1990 Marriott Hotel, Anaheim, CA 

They also sponsor workshops, such as 

Apr 9-10 1987 Palace Hotel, Philadelphia, PA 

Large Installation System Administrator's Workshop 
Oct 8- 9 1987 Cambridge Marriott, Cambridge, MA 
4th USENIX Computer Graphics Workshop 
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Proceedings for all conferences and workshops are available at 
the door and by mail later. 

USENIX publishes ’’/login: The USENIX Association Newsletter" 
bimonthly. It is sent free of charge to all their members and 
includes technical papers. There is a USENET newsgroup, 
comp.org.usenix, for discussion of USENIX-related matters. 

They also publish an edition of the 4.3BSD manuals, and they 
occasionally sponsor experiments, such as methods of improving 
the USENET and UUCP networks, that are of interest and use to 
the membership. They also distribute tapes of contributed software 
and are pursuing expanding that activity. 


EUUG is the European UNIX systems Users Group. 

EUUG secretariat 
Owles Hall 
Buntingford 
Herts SG9 9PL 
England 

seismo!mcvax!euug 

They have a newsletter and hold two conferences a year. 


AUUG is the Australian UNIX systems users Group. 


There is a USENIX Institutional Representative on the IEEE P1003 
Portable Operating System for Computer Environments Committee. 

That representative also moderates the USENET newsgroup mod.std.unix, 
which is for discussion of UNIX-related standards, especially P1003. 
For more details, see the posting in mod.std.unix about Access 
to UNIX-Related Standards. 


/usr/group is "the commercially oriented UNIX system users organization." 
/usr/group 

4655 Old Ironsides Drive, Suite 200 
Santa Clara, California 95054 
408-986-8840 


AUUG 

P.0. Box 366 
Kensington 
N.S.W. 2033 
Australia 

seismo!munnari!auug 
auug@munnari.oz.au 

Phone contact can occasionally be made at +61 3 344 5225 

AUUG holds biennial conferences, usually of 2 days each: 
the next one will probably be in late February 1986. 

They publish a newsletter (AUUGN) at a frequency defined 
to be every 2 months. 


The annual UniForum Conferences are sponsored by /usr/group and feature 
a large trade show, as well as tutorials and technical sessions. 

Feb 10-12 1988 Infomart, Dallas, TX, concurrent with USENIX 
March 1989 San Francisco 

Winter 1990 Washington, D.C. 

They have also started a regional show: 

August 1988 Washington, D.C. 

/usr/group publishes a bimonthly newsletter called CommUNIXations, 
which includes much current industry news. 

They also publish the UNIX Products Directory, which offers 
information on UNIX-related products. 

/usr/group has long been deeply involved in UNIX standardization, 
having sponsored the /usr/group Standard, providing an Institutional 
Representative to the IEEE P1003 Portable Operating System for Computer 
Environments Committee, and sponsoring the /usr/group Working Groups 
on areas.that P1003 has not yet addressed. For more details, see the 
posting about Access to UNIX-Related Standards. 


There are similar groups in other parts of the world, such as Japan and 
Korea. If such a group wishes to be included in later versions of this 
access list, they should please send me information. 


Also, DECUS, the Digital Equipment Computer Users Society, 
has a UNIX SIG (Special Interest Group) which participates 
in its meetings, which are held twice a year. The next 
one will be in Nashville, Tennessee, 27 April - 1 May 1987. 

DECUS U.S. Chapter 
219 Boston Post Road, BP02 
Marlboro, Massachusetts 01752-1850 
617-480-3418 

See also the USENET newsgroup comp.org.decus. 


The two main general circulation magazines about the UNIX system are 


UNIX REVIEW 

Miller Freeman Publications 
500 Howard Street 
San Francisco, CA 94105 
415-397-1881 


UNIX/WORLD 

Co. Tech Valley Publishing 
444 Castro St. 

Mountain View, CA 94041 
415-940-1500 
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UNIX BACKUP UTILITIES AND STRATEGIES TO USE THEM 

or 

WHY BRUSH YOUR TEETH 
Nancy Bl&chman 

Research Institute for Advanced Computer Science (RIACS) 

NASA Ames Research Center, MS 230 - 5 
Moffett Field, CA 94035 
ARPA: nancy@riacs.edu 
UUCP: hplabslriacslnancy 
Copyright 1986 by Nancy Blachman 

Making backups is like brushing your teeth: it takes time, you 
don’t feel any benefit unless a disaster strikes, and then you wish 
you had taken it more seriously. Both for backups and cleaning 
teeth, there are several tools which can be used in a variety of ways 
and some are more effective than others. This paper will describe 
the Unix backup utilities and discuss strategies for using them. 


Backups are useful in a variety of situa¬ 
tions including when a systems person 
accidentally format disks, or run newfs, when 
hardware fails, when a controller breaks and 
scribbles on the disk, or when an earthquake or 
fire destroys a whole computer center. 

After such a disaster occurs, you may find 
that you have no backup tapes. The backups 
may be out of date, or the tapes may be 
unreadable. 

This paper describes ways of avoiding the 
disastrous situations described above. 

1. UNIX BACKUP UTILITIES. Each version 
of Unix has its own backup utilities. This sec¬ 
tion describes the utilities available for produc¬ 
ing and restoring backups on System V, Ver¬ 
sion 7, and ^ 4.2 Berkeley Standard Distribu¬ 
tion (BSD) UNIX systems. Version 7 systems 
include Xenix, 2.9 and 4.1 BSD systems. 

1.1. SYSTEM V has four programs intended 
specifically for performing backups: ff ’ volcopy, 
fine , and free. 

ff produces a table of contents, a list of i- 
nodes and path names. I-nodes are internal 
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numbers Unix uses to identify files. 
volcopy copies an entire filesystem, fine is a 
flexible program that copies only files which 
have changed within the period of time tlv 
operator specifies, free recovers files from a 
volcopy or fine backup. 

The system V backup utilities are awk¬ 
ward to use because they require i-nodes rather 
than file names as arguments. Developing a 
front-end program to free could make it easier 
to use. 

1.2. VERSION 7 backup utilities are easier to 
use than those of System V, but they are not 
as flexible. The Version 7 backup utilities are 
dump, dumpdir, and restor. Note that restor is 
spelled without the expected final e. 

dump uses the concept of dump levels. 
Dump level 0 corresponds with a backup of the 
entire filesystem. Levels 1 through 9 include 
all changes since the most recent backup with 
a lower level number. In other words, if you 
make a level 3 dump, change some files, and 
then dump at level 4, only the files which have 
changed since the level 3 dump are saved. 
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Like the System V utility ff\ dump pro¬ 
duces a table of contents. It also stores the 
time and date of the most recent dump at each 
level, in the file /etc/ddate. dumpdir lists the 
files on a tape. 

restor retrieves files from a dump, using 
the actual file names. Unfortunately, the 
restored files are assigned i-nodes as names. 
The shell script rename in the Appendix reas¬ 
signs the original names to restored files. 

1.3. ULTRIX AND ^ 4.2 BSD Unix have two 
backup utilities: dump, and restore. In addi¬ 
tion, rdump and rrestore can dump and restore 
files across a local area network. 

dump is similar to its counterpart in Ver¬ 
sion 7, except it stores dump dates in 
/etc/dumpdates in human-readable form, as 
shown below. The first column contains the 
filesystem, the second column the dump level. 

/dev/hpOg 0 Sun Dec 1 10:14:38 1985 

/dtv/hpOh 0 Sun Dec 1 10:58:43 1985 

/dev/hpOg 3 Tue Dec 3 07:03:54 1985 

A sample /etc/dumpdates file. 

dump in 4.2 BSD handles tape problems 
better than the other standard Unix backup 
utilities. When the program encounters a bad 
tape, it will request and accept a new tape 
rather than aborting the entire dump. 

Unlike the Version 7 restor, restore can 
list the files on a tape and it automatically 
restores files with their original name. With 
its interactive mode, you can examine the con¬ 
tents of a backup as if it were on the system. 
However, first-time users are sometimes con¬ 
fused because files to be extracted are put on a 
list. To obtain the requested files, type extract. 

1.4. ARCHIVE UTILITIES. Every UNIX sys¬ 
tem has utilities for writing on tape. The most 
common of these utilities are tar and cpio. 
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1.4.1. TAR format tapes can be read on most 
UNIX machines. Unfortunately, tar cannot 
deal with more than one physical volume of 
backup medium, and there is a limit to the 
number of characters that can be passed to tar 
as arguments. 

Here is an example of how to use tar to 
save all files in the directory /usr that are at 
most four days old: 

tar e l find /usr - mtime -4 -print \;‘ 

1.4.2. CPIO, like tar , can backup files in 
different filesystems. Unfortunately, Version 7 
and BSD systems cannot read cpio format 
tapes. 

Here is an example of how to use the cpio 
option of find to save all files in the directory 
/usr less than four days old on tape: 

find /usr - mtime -4 - cpio /dev/rmtO ; 

2. CRITERIA FOR BACKUPS. The next sec¬ 
tion discusses some of the criteria to consider 
when when selecting or designing a backup 
strategy. 

2.1. WHAT IF YOUR TAPE GOES BAD? 
There is always a possibility that the medium 
on which a backup is stored will go bad. Thus, 
it is wise to have two copies of each backup 
file. The probability that both backups would 
fail at the same time is low. Later sections 
suggest strategies for acquiring two copies of 
each backup. 

2.2. SELF-CHECKING. Do not wait until a 
disk goes bad to see if the backups are good. 
There should be an automated procedure to 
check that backups are readable. 

Reading the last file off a dump tape is a 
way of verifying a backup. The Appendix con¬ 
tains a shell script which uses this method to 
verify ^ 4.2 BSD dumps. 
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2.3. RETIRE OLD TAPES and FLOPPIES 
before they reach the end of their useful lives. 
Put old tapes and floppies into the permanent 
archives. 

2.4. MAKE THE BACKUP SYSTEM EASY TO 
USE so the task will not be avoided. For a 
backup strategy to be effective, it must be 
adhered to. 

2.5. BACKUP WHEN there is a minimum of 
system activity, since files that change while 
making a backup may be stored incorrectly. 

The frequency with which backups to 
make backups depends on how much informa¬ 
tion you can afford to lose. Most sites choose 
to make backups every working day. A com¬ 
plete or epoch dump should be made before 
replacing your computer. 

2.6. WHEN RESTORING FILES, the 4.2 BSD 
and Version 7 manuals suggest mounting 
dump tapes in reverse order, dump copies files 
in increasing order of i-node and writes the i- 
node of the first file in the header of the tape. 
If the i-node of the file requested is too low to 
be on the volume mounted, both restore and 
restor do not read the rest of the tape. 

The 4.2 BSD dump program tells the 
operator the i-node of the first file stored on 
each tape of a multi-volume backup. Make it a 
part of your backup procedure to write this 
information on each tape’s label. Use the ver¬ 
bose option of the 4.2 BSD restore program, 
which gives each file’s i-node, to determine the 
tape volumes you need. 

2.7. IF YOU HAVE EXCESS DISK SPACE, 
consider dumping modified files onto disk dur¬ 
ing a time when few files are changing, and 
then writing (with dd) the dumped files on 
tape or another storage medium at a more con¬ 
venient time. Files can then be extract from 
the tape with the appropriate restore 


command. There are several advantages to 
this scheme: (1) Dumped files are more likely 
to be consistent. (2) Dumps can be run from 
cron late at night. (You might not want to 
update the file containing dump dates until 
backups are written to tape.) (3) If a file or 
filesystem is lost while the backup file is still on 
the system, it is more convenient to recover 
from the backup information on disk than 
from tape. (4) If you devote an entire disk 
drive for doing backups, that disk can replace 
a failing disk until repairs can be made. 

2.8. SECURITY. If you want your system to 
be secure, then keep your backups secure. If a 
user can access the backups, then she can see 
any file on the backups. 

2.9. PORTABLE. Backups are usually read on 
the machine they are written on. However, if 
your machine has caught fire or you upgrade 
to a new computer, it will be useful to be abl 
to read your backups on another machine. 

2.10. EFFECTIVENESS. For a backup scheme 
to be effective, you must be diligent, label all 
backups, verify backups, and keep some back¬ 
ups off-site. 

3. A BACKUP STRATEGY should minimize 
possible losses. Be aware that whenever you 
manage to restore data, the users will have to 
repeat all work done since the last backup. 

This section describes dumping strategies, 
ways of using the dump utilities to make back¬ 
ups. Although the strategies use the concept of 
Version 7 and 4.2 BSD dump levels, these stra¬ 
tegies can also be used on computers running 
System V. Level 0 are full or epoch dumps. 
Levels 1 through 9 are partial or incremental; 
dumps consisting of the files that have changed 
since a previous lower level dump. 


3.1. THE DAILY TAPES GROW AS THE 
WEEK GOES BY scheme uses three levels of 
backup. Level 0 or full dumps are made on the 
last Friday of the month, level 1 dumps are 
made on all other Fridays, and level 2 dumps 
are made on other days. Figure 1 is a graphic 
representation of this system. The lines show 
the amount of material that is written to tape, 
and tape symbols designate days of the week 
when backups are made. 



This simple scheme and offers excessive 
redundancy. A file made on Monday will be 
stored on at least four tapes. A file made on 
the first Monday of the month will be stored 
on six or seven tapes. 

3.2. SMALL DAILY TAPES scheme suggested 
by the Intel Xenix System Administrator’s 
Guide offers little redundancy. 

To implement this system, make an epoch 
or level 0 dump once a month on a Saturday, 
when no users are on the system. Skip the 
weekly dump the following Monday but on suc¬ 
cessive Mondays make a level 1 dump, then a 
level 2, and finally a level 3. On Tuesdays, 
make a level 5 dump, on Wednesdays, a level 
6, on Thursdays, a level 7, and on Fridays a 
level 8, as shown in figure 2. 

This scheme is easy to understand and 
teach. Since there is little redundancy, less 
data is written to tape than with almost any 



Figure 2. The Small Daily Tapes Dump Strategy 


other scheme, saving CPU time, wall clock 
time, and possibly tape. 

Lack of redundancy increases the chance 
that a magnetic tape or disk failure will make 
it impossible to bring everything back. With 
small tapes restores can involve the mounting 
of many tapes. For example, if a filesystem is 
destroyed on the Friday before an epoch dump, 
eight tape sets will have to be restored. 

This strategy though not as robust as 
other strategies, is reasonable for a microcom¬ 
puter with a floppy disk drive. Floppies have 
little capacity and tend to be more reliable 
than tape. 

3.3. THE VERSION 7 TOWER OF HANOI, 
according to the manual, makes incremental 
backup "on an exponential progression of 
tapes.” That is, after making a full or level 0 
dump, make level 9 dumps using tapes rotated 
according to the Tower of Hanoi sequence 
which is illustrated below: 

121312412131 .... 

Start with a set of tapes, 5 will be enough 
for most cases. The fir^t level 9 dump goes on 
tape 1. The second level 9 dump goes on tape 
2, and the third goes on tape 1 again. The 
fourth level 9 dump goes on tape 3, etc. When 
the level 9 incremental approaches a full tape, 
make a level 1 dump. If you have not put it off 
too long, this will usually fit on a single tape. 
After making the level 1, continue making level 
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9 dumps as before, using tapes according to 
the Tower of Hanoi, until the incremental 
again nearly fills a single tape. At this point, 
make a level 2 dump. Continue this progres¬ 
sion until you have made a level 8 dump and 
level 9 dumps no longer fit on a single tape or 
until you are otherwise ready to make an 
epoch dump, then start the sequence over 
again. 



Figure 3. The Version 7 Tower of Hanoi Dump Strategy 


As can be seen in Figure 3, this scheme 
provides redundancy on the incremental back¬ 
ups, which are the tapes subject to the most 
wear. It also uses tape efficiently in that the 
lower level dump tapes will tend to be nearly 
full. If an incremental backups only require a 
single tape, it is possible to mount a tape at 
night and run the dump from cron . 

3.4. HALF REDUNDANT OR THE MODIFIED 
TOWER OF HANOI is recommended in the 
4.2 BSD Unix manual page for dump. This 
scheme consists of performing incremental 
dumps according to the sequence listed below. 

32547698932... 

Weekly dumps are made at level 1 and 
monthly dumps at level 0. 

The sequence is called a modified Tower of 
Hanoi algorithm even though it has little if 
anything to do with the Tower of Hanoi. 

As is shown in figure 4, with this scheme 
there are at least two copies of half the files on 
the system. 



The shell script dumplevel in the Appendix 
keeps track of the dump levels for this scheme. 

3.5. TANDEM DUMPING OR THE MINIMUM 
FULL REDUNDANCY scheme, shown in 
figure 9, was inspired by Berkeley’s so-called 
modified Tower of Hanoi. Berkeley’s scheme is 
a step in the right direction but goes only half 
way. 

Some backup schemes store a file on only 
one tape at some point in their sequence. Oth¬ 
ers store a file more than twice. Some schemes 
do both. This scheme only writes two tape 
images of files added to the system (see Figure 
*)• 



Figure 5. Tandem Dumping (Minimum Full Redundancy) 

In Version 7, Ultrix and ^ 4.2 BSD system, 
implement this scheme by maintain two dum 
date files. Run dump A with the sequence 


0123456789 on even days and dump B with 
the same sequence on odd days. The shell 
script swapdump in the Appendix shows how to 
swap between two dumpdate files. 

Be sure to copy the level 0 entry for that 
filesystem to both dumpdatesA and dump- 
datcsB. 

3.6. THE SINGLE TAPE SCHEME selects the 
dump level based on how much the filesystem 
has changed. This scheme dumps at the lowest 
level possible that will fit on a single tape. If 
many new files are continually added, then this 
scheme will dump at an increasingly higher 
level. If so much changed on the system that 
the changes do not fit on a single tape, then 
the system administrator will be notified that 
it is time to do an epoch dump. 

This scheme is most easily implemented 
with the aid of a spare filesystem or by altering 
the dump program to provide an estimate of 
the dump size. If you have a large enough 
spare filesystem, then you can dump the 
filesystem to a file on it and check the size of 
the file. If the dump file could not fit on a sin¬ 
gle tape, the dump file is removed and the 
dump level is increased. On the other hand, if 
you alter the dump program to give an esti¬ 
mate of the size of the dump, you could use 
that option and avoid trial dumps. With this 
scheme, cron can dump from filesystem to 
filesystem at night. The dump file can be writ¬ 
ten to tape during the day using the dd com¬ 
mand. 

Redundancy is provided by retaining a 
dump at each level dumped as well as the pre¬ 
vious dump at that level, if it exists. 

The advantages of this single tape scheme 
is that the the number of backup tapes pro¬ 
duced per day is predictable. This scheme uses 
tapes efficiently; saved tapes will be as full as 
possible. 



The disadvantages of the scheme are that 
it uses more CPU time than the other schemes 
and it is best to have extra disk space to imple¬ 
ment this scheme. 

The Single Tape Scheme is most appropri¬ 
ate for systems with extra disk space, spare 
CPU cycles that can be used at night. Incre¬ 
mental will tend to fit on a single tape if you 
have a high density tape drive or your filesys¬ 
tem does not change much. 

4. CONCLUSION. Figures 7 and 8 summarize 
the backup schemes which have been discussed 
in this paper. There is no optimal scheme for 
all environments. If data is crucial or costs a 
great deal to reproduce, dump frequently. 
Sites with floppy drives or where data can be 
reproduced may want to minimize the size of 
dumps by using the Small Tape scheme or a 
similar strategy. The Single Tape scheme is 
best for sites with extra disk space. 

No matter which version of Unix you have 
on your system, you can to combine the stan¬ 
dard backup utilities with good backup prac¬ 
tices to create a backup scheme which balances 
your possible losses with the resources you 
want to devote to backups. 

Remember for a backup scheme to be 
effective, it is important to be diligent, label 
backups accurately and clearly, verify backups, 
and keep copies off-site. 
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Daily Tapes Grow as the Week Goes by 
•simple 

•provides much redundancy 

Small Daily Tapes 
•small tapes 
•little redundancy 
•best for system 

•with floppy drives 
•where data not critical 

Version 7 Tower of Hanoi 

•efficient tape usage (tapes tend to be full) 

Half Duplicating or Modified Tower of Hanoi 
•write files to tape few times 
•two copies of half the files backed up 

Tandem 

•write files to tape few times 
•two copies of all files backup up 

Single Tape 

•few tapes required to restore file system 
•tapes used efficiently (tapes tend to be full) 

•cpu intensive 

•best for systems with extra disk space 
Figure 7. An overview of the backup strategies described in this article. 


PAGE 32 Fall 1986 UNISIG session notes 


UNI-22 


Scheme 

# of 

Tapes 

per 

Incre¬ 

mental 

Avg # 
Copies 
of File 
on Tape 

Avg # 
Times 
File 

Written 
to Tape 

Freq 

of 

Epoch 

Dumps 

Avg # 
of Levels 
Needed for 
Restore 

Daily Tapes 
Grow As the 
Week Goes By 

1 or more 

1-4 

1-4 

1 month 

2-3 

Small Daily 

1 

1 

1 

1 month 

2-8 

Tower of Hanoi 

1 

1-3 

1-many 

unknown 

2-10 
but low 

Half Duplicate 

1 or more 

1-2 

1-2 

1 month 

2-5 

Tandem 

1 or more 

2 

2 

1 month 

2-5 

Single Tape 

1 

1-18 

1-many 

unknown 

2-10 


but low 


Figure 8. A summary of the backup strategies discussed in this article. 
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APPENDIX 


EXAMPLE 1: RENAME 

: rename 

: To rename files retrieved from a Version 7 dump to the original name, 

: To use, get a list of i-nodes and final pathname from dumpdir, and 
: put them in a file. Then edit the file so it contains only the i-nodes 
: and names of the files to be retrieved from the backup. Feed this 
: information to this shell script rename. Run the output through sh. 

while read in 
do 

set ‘echo $in‘ 

INODE=$l 

PATHNAMES 

FINALNAME=$PATHNAME 

OIFS=$IFS 

IFS=/ 

set ^PATHNAME 

IFS=$OIFS 

DIR=. 

while test -ge 2 
do 

DIR=$DIR/$1 
echo mkdir $DIR 
shift 

done 

echo mv SINODE .SFINALNAME 

done | sort -u 
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EXAMPLE 2: DUMP VERIFY 

#!/bin/sh 

f dump.verify verify that a dump worked (4.2 BSD Unix) 

* 

if test $ # -eq 0 
then 

DUMPDE VICE=/dev/rmt8 

else 

case "$l fl in 

/*) DUMPDEVICE="$1" 

*) DUMPDEVICE=‘pwd‘/"$l" 

esac 

fi 

PATH=/bin:/etc:/usr/ucb:/usr/bin 

TMP=/tmp/dump.verify.$$ 

mkdir $TMP 
cd $TMP 

f Get the name of the last file on the dump, and restore it. 
lastfile=‘restore tf SDUMPTAPE | sort -n | tail -f | awk ’{print $2 } M 

echo $0 : restoring the file $lastfile 

echo ******************************************************************* 

echo ’** Even though restore tells you to start with the last volume’ 

echo ’** start with volume 1 and work toward the last volume.’ 

echo ’** In other words, mount the tapes in sequential order.’ 

echo ’*********************************^ 

if restore xf SDUMPTAPE "Slastfile" 

then 

Is -1 "llastfile" 

if test -f "Slastfile" -o -d "Slastfile" 
then 

echo; echo ’dump.verify: verification succeeded’; echo 
rm -frn $TMP 
exit 0 
fi 
fi 

echo; echo dump.verify’: ****** VERIFICATION FAILED ******’; echo 
rm -fr $TMP 


Fall 1986 UNISIG session notes PAGE 35 


UNI-25 


EXAMPLE 3: DUMPLEVEL 

#!/bin/sh 

# dumplevel 

f Determine level for next dump, according to the half redundant or so-called 

# modified Tower of Hanoi sequence suggested in the 4.2 BSD Unix Manual. 
PATH=/bin 

LEVEL=.level 


if test -f &LEVEL 
then 

f Level of previous dump 
level=‘awk ’{print $1 }’ $LEVEL l 

else 

level=0 

fi 

if test $ level -eq 0 -o $ level -eq 8 
then 


# start of Tower of Hanoi 
newlevel=3 

if test ‘expr $ level % 2 l -gt 0 
then 

f level is odd 
newlevel=‘expr $ level - 1‘ 

else 

f level is even 
newlevel=‘expr Slevel + 3‘ 
fi 


fi 

# Put new level in file 
echo M $newlevel M > SLEVEL 


EXAMPLE 4: SWAPDUMP 

#! /bin/sh 
f swapdump 

# This program swaps dumpdatesA and dumpdatesB. 

f Invoke before performing daily dumps to implement tandem dumping. 

rm /etc/dumpdates 

In /etc/dumpdatesA /etc/dumpdates 

rm /etc/dumpdatesA 

mv /etc/dumpdatesB /etc/dumpdatesA 

In /etc/dumpdates /etc/dumpdatesB 
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Survey regarding Tailoring for VAX/VMS V5.0 


To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with 
the username PAGESWAPPER. 

Articles for publication in the Pageswapper can be sent (US mail 
only -- no "express" services please) to: 

Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139^0901 
USA 

Preference is given to material submitted as machine-readable 
text (best is Runoff source). Line length should not exceed 64 
characters and the number of text lines per page should not 
exceed 48 (these limits are particularly important for sample 
commands, etc. where simple text justification will not produce 
a meaningful result) . 

Please do not submit program source, as that is better 
distributed on the VAX SIG tape. 

Please do not submit "slides" from DECUS Symposia presentations 
(or other meetings) as they are generally a very incomplete 
treatment for those readers of the Pageswapper who are not so 
fortunate as to be able to travel to Symposia. Please DO write 
articles based on such slides to get the content across to a 
wider audience than is able to attend. 

Change of address, reports of non-receipt, and other circulation 
correspondence should be sent to: 

DECUS U.S. Chapter 

Attention: Publications Department 
249 Northboro Road (BP02) 

Marlborough, MA 01752 
USA 

Only if discrepancies of the mailing system are reported can 
they be analyzed and corrected. 


Survey Regarding Tailoring for VAX/VMS V5.0 


The VMS development group is considering an alternate tailoring 
mechanism to be used for both VAX and MicroVAX systems. Such a 
mechanism could show up in the next major release of VMS. As 
part of this design effort, they would like to gather 
information from the current user base. Please, would only the 
people who feel that they will use tailoring return the form at 
the back of this newsletter issue to DEC. 


The currently proposed design is comprised of three save sets: 
the base set, the library set, and the optional set. The 
division of them is roughly: 

BASE - components necessary for all systems to boot 
LIBRARY - programming support, system programming, etc. 
OPTIONAL - UETP, example files, etc. 


The BASE save set (approx. 15,000 blocks total) is the one that 
we need input on. Most of the files will not be tailorable. 
Only the following categories are being considered for 
tailoring: 


(System-specific files) 

Layered product kit building 

Console block storage device support 

VAX 11/725, 11/730 support 

VAX 11/750 support 

VAX 11/780 support 

VAX 8600 support 

VAX 8200,8300 support 

VAX 8500, 8700, 8800 support 

MicroVAX I, VAXstation I support 

MicroVAX II, VAXstation II support 

VAXstation 2000/MicroVAX 2000 support 

(Total: 


(10 blocks) 
(180 blocks) 
(35 blocks) 
(26 blocks) 
(35 blocks) 
(53 blocks) 
(45 blocks) 
(52 blocks) 
(46 blocks) 
(85 blocks) 
(81 blocks) 
578 blocks) 


(Bus-specific device drivers) 

Realtime device drivers 
Massbus drivers 
Cl drivers 
BI drivers 
Unibus/Qbus drivers 

MicroVAX 2000, VAXstation 2000 drivers 

(Total: 


(6 blocks) 
(32 blocks) 
(64 blocks) 
(110 blocks) 
(176 blocks) 
(78 blocks) 
466 blocks) 


VAX-2 


VAX- 
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(Files needed to run clusters) 

Cluster Support (approx. 1000 blocks) 

(approx. grand total: 2000 blocks) 

The fine divisions above allow for greater control on saving 
disk space. However, this fine granularity causes the following 
problems: 

* A user will be unable to build a system disk that will 
work on other systems from a tailored system disk using 
VMSKITBLD.COM. 

Users may have to re-install portions of the base save 
set when they buy new hardware. 

“ A naive user may potentially delete a file that he 
needs to reboot his system. 


Again, the questionnaire regarding these considerations can be 
found at the back of this issue. If you are someone who needs 
to use the tailoring facility, please fill it out and mail it. 
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Spring 1987 SIR Ballot Results 


Mark Oakley 
SIR Coordinator 

A total of 364 ballots were counted in the latest SIR BALLOT. 
This is less than the record turn-out for the Fall 1986 ballot, 
but about the same as the Spring 1986 ballot. For the first 
time it was possible to cast votes electronically via the 
Pageswapper Vax. Many thanks to Larry Kilgallen for the use of 
the Pageswapper Vax and for his "ballot^casting" procedure. I 
am hopeful that participation will continue to build, and will 
look for ways to encourage you to vote. 

The SIR ballot is the only on-going program by which the SIG 
provides input to Digital. Top 10 (and other) SIR'S continue to 
be incorporated into VMS. Digital has repeatedly encouraged the 
use of this channel of communication. I recently met with 
several Digital managers in Nashua and they emphasized there 
interest and commitment to this program. 

The summary of this voting appears below. Digital*s response to 
the top 10 requests overall will be presented at the Spring 1987 
DECUS Symposium in Nashville. 

Interpreting the SIR Ballot Results 

The results of the System Improvement Request ballot are shown 
on the following pages. All of the reports have the same one 
page format. Following the report title is the number of 
ballots counted for that report. The number shown on the "All 
Users" report is the total number of ballots which were 
returned. The ballots on the "11/780 Users" report is the 
number of ballots which checked the "11/780" blank on the ballot 
questionnaire, and so on. 

The SIR'S are listed on the page in order of points received, 
from highest to lowest. The entry for each SIR begins with the 
SIR number (from the ballot), a brief description, and the total 
number of votes (positive and negative) received by that SIR. 
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The data is summarized in two different ways. First, there are 
a series of reports broken down by user category. The user 
categories are defined by the questionnaire portion of the SIR 
ballot. A ballot was counted in each user category which was 
checked off, for example "11/780 user". Finally, there are a 
series of reports ranking the SIR's within SIR category. The 
SIR categories are those shown on the ballot, for example "DCL 
and Utilities" and "Commercial". The reports by SIR category 
use the data from all ballots received. 


THE TOP 35 SIR'S AS RANKED BY ALL USERS 


Total ballots in this category: 364 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 215 

28 Enforce expired password change 158 

27 Remote printing of a LOCAL file 156 

20 Provide "date last read" for a file 145 

77 Individual field reports from AUTHORIZE 133 

71 Support BACKUP over DECnet. 130 

1 Additional VAXcluster management tools 119 

51 Ability to redstart a process 108 

57 Support ACL's on print and batch queues 104 

56 Display special characters in TPU 99 

16 Queued requests for ALLOCATE command 92 

44 Internals and data structures documents 89 

19 Standardize format for printable output. 83 

49 Determine the source of LAT terminals. 81 

21 Support for simple project accounting. 81 

24 Installable memory resident images 73 

76 Terminal server accounting info 72 

6 More detail in VMS accounting records 70 

35 More system information on open files 70 

60 Enhance COPY to copy ACL's 68 

17 Tape automatic volume recognition 68 

4 Abbreviated commands in DTR 66 

9 Improve VMS Mount service messages 62 

74 Printer problem warnings to users 62 

2 Better SYSUAF.DAT cluster support 57 

82 "Fast" delete for directory structures 57 

80 Command procedure capability in STB 55 

18 Provide a BACKUP/OPERATOR capability. 54 

47 Tape librarian/archive system 50 

43 2-way inter-process comm driver 50 

65 Security alarm messages to a file. 49 

83 "Headers" and "footers" on printed outpu 49 

12 Improve form name/number displays 45 

62 Enhance file access from user images 45 

79 Boot STB from tape drive 43 
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THE TOP 35 SIR'S AS RANKED BY VAX 8700/8800 USERS 


Total ballots in this category: 30 Spring 1987 Ballot 

SIR SIR Total 

No, Description Votes 

26 Command line editing for long commands 17 

16 Queued requests for ALLOCATE command 15 

1 Additional VAXcluster management tools 15 

27 Remote printing of a LOCAL file 15 

17 Tape automatic volume recognition 14 

28 Enforce expired password change 13 

49 Determine the source of LAT terminals. 12 

20 Provide "date last read" for a file 11 

76 Terminal server accounting info 11 

65 Security alarm messages to a file. 10 

44 Internals and data structures documents 10 

21 Support for simple project accounting. 9 

14 Selected operator notification queues 8 

47 Tape librarian/archive system 8 

2 Better SYSUAF.DAT cluster support 8 

56 Display special characters in TPU 8 

62 Enhance file access from user images 8 

3 Process swapping between nodes 8 

71 Support BACKUP over DECnet. 8 

9 Improve VMS Mount service messages 8 

51 Ability to re-start a process 7 

6 More detail in VMS accounting records 7 

77 Individual field reports from AUTHORIZE 7 

40 System service to flush accounting 6 

36 LEXICAL to return process identifiers 6 

67 Lexical for getting RIGHTSLIST info 6 

19 Standardize format for printable output. 5 

12 Improve form name/number displays 5 

35 More system information on open files 5 

4 Abbreviated commands in DTR 5 

74 Printer problem warnings to users 5 

18 Provide a BACKUP/OPERATOR capability. 5 

57 Support ACL's on print and batch queues 5 

82 "Fast" delete for directory structures 5 

23 Time out mechanism for $REQUEST/REPLY 4 


THE TOP 35 SIR'S AS RANKED BY VAX 8600/8650 USERS 


Total ballots in this category: 88 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 57 

1 Additional VAXcluster management tools 54 

27 Remote printing of a LOCAL file 47 

20 Provide "date last read" for a file 37 

44 Internals and data structures documents 30 

71 Support BACKUP over DECnet. 30 

17 Tape automatic volume recognition 29 

51 Ability to re-start a process 28 

28 Enforce expired password change 28 

56 Display special characters in TPU 27 

57 Support ACL's on print and batch queues 27 

49 Determine the source of LAT terminals. 27 

16 Queued requests for ALLOCATE command 26 

77 Individual field reports from AUTHORIZE 25 

6 More detail in VMS accounting records 24 

76 Terminal server accounting info 20 

9 Improve VMS Mount service messages 20 

21 Support for simple project accounting. 19 

2 Better SYSUAF.DAT cluster support 19 

19 Standardize format for printable output. 17 

62 Enhance file access from user images 15 

65 Security alarm messages to a file. 14 

43 2-way inter-process comm driver 14 

35 More system information on open files 13 

54 Enhance line number support 13 

4 Abbreviated commands in DTR 13 

83 "Headers" and "footers" on printed outpu 13 

3 Process swapping between nodes 12 

47 Tape librarian/archive system 12 

36 LEXICAL to return process identifiers 12 

58 Enhance DECnet remote file access 12 

82 "Fast" delete for directory structures 12 

18 Provide a BACKUP/OPERATOR capability. 12 

74 Printer problem warnings to users 11 

75 Queue name language/utility recognition 11 
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THE TOP 35 SIR * s AS RANKED BY VAX 8500/8550 USERS 


Total ballots in this category: 13 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 9 

16 Queued requests for ALLOCATE command 7 

1 Additional VAXcluster management tools 7 

27 Remote printing of a LOCAL file 7 

51 Ability to redstart a process 7 

49 Determine the source of LAT terminals. 6 

57 Support ACL 1 s on print and batch queues 6 

20 Provide "date last read" for a file 5 

2 Better SYSUAF.DAT cluster support 5 

17 Tape automatic volume recognition 4 

19 Standardize format for printable output. 4 

7 Better terminal-printer support 4 

56 Display special characters in TPU 4 

3 Process swapping between nodes 4 

74 Printer problem warnings to users 4 

9 Improve VMS Mount service messages 3 

12 Improve form name/number displays 3 

55 Ignore TPU journal requests for help 3 

36 LEXICAL to return process identifiers 3 

43 2-^way intern-process comm driver 3 

65 Security alarm messages to a file. 3 

71 Support BACKUP over DECnet. 3 

44 Internals and data structures documents 3 

75 Queue name language/utility recognition 3 

79 Boot STB from tape drive 3 

54 Enhance line number support 2 

34 Full name translation of DCL files 2 

35 More system information on open files 2 

13 Form names beyond 127. 2 

58 Enhance DECnet remote file access 2 

62 Enhance file access from user images 2 

23 Time out mechanism for $REQUEST/REPLY 2 

18 Provide a BACKUP/OPERATOR capability. 2 

73 Additional file attributes in BACKUP 2 

47 Tape librarian/archive system 2 
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THE TOP 35 SIR'S AS RANKED BY VAX 8300/8200 USERS 


Total ballots in this category: 46 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

27 Remote printing of a LOCAL file 25 

26 Command line editing for long commands 23 

28 Enforce expired password change 22 

1 Additional VAXcluster management tools 20 

76 Terminal server accounting info 17 

16 Queued requests for ALLOCATE command 16 

21 Support for simple project accounting. 16 

77 Individual field reports from AUTHORIZE 14 

20 Provide "date last read" for a file 13 

57 Support ACL's on print and batch queues 12 

51 Ability to redstart a process 11 

2 Better SYSUAF.DAT cluster support 11 

18 Provide a BACKUP/OPERATOR capability. 10 

60 Enhance COPY to copy ACL's 10 

49 Determine the source of LAT terminals. 10 

19 Standardize format for printable output. 10 

56 Display special characters in TPU 9 

71 Support BACKUP over DECnet. 9 

65 Security alarm messages to a file. 8 

67 Lexical for getting RIGHTSLIST info 8 

44 Internals and data structures documents 8 

9 Improve VMS Mount service messages 8 

32 Mechanism to ignore ZERO LENGTH FILES. 8 

40 System service to flush accounting 7 

42 Run-time library routine to purge files 7 

4 Abbreviated commands in DTR 7 

74 Printer problem warnings to users 7 

35 More system information on open files 7 

62 Enhance file access from user images 7 

83 "Headers" and "footers" on printed outpu 7 

3 Process swapping between nodes 6 

43 2-way inter-process comm driver 6 

36 LEXICAL to return process identifiers 6 

58 Enhance DECnet remote file access 6 

47 Tape librarian/archive system 6 
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THE TOP 35 SIR'S AS RANKED BY 11/780, 11/782 and 11/785 USER 


Total ballots in this category: 229 Spring 1987 Ballot 

SIR SIR Total 

No, Description Votes 

26 Command line editing for long commands 135 

27 Remote printing of a LOCAL file 107 

28 Enforce expired password change 99 

20 Provide "date last read" for a file 98 

1 Additional VAXcluster management tools 97 

71 Support BACKUP over DECnet. 88 

77 Individual field reports from AUTHORIZE 88 

51 Ability to re-start a process 78 

57 Support ACL's on print and batch queues 78 

16 Queued requests for ALLOCATE command 66 

56 Display special characters in TPU 61 

17 Tape automatic volume recognition 58 

49 Determine the source of LAT terminals. 57 

44 Internals and data structures documents 57 

6 More detail in VMS accounting records 54 

76 Terminal server accounting info 49 

21 Support for simple project accounting. 49 

2 Better SYSUAF.DAT cluster support 46 

4 Abbreviated commands in DTR 45 

19 Standardize format for printable output. 42 

9 Improve VMS Mount service messages 41 

18 Provide a BACKUP/OPERATOR capability. 37 

35 More system information on open files 37 

24 Installable memory resident images 36 

47 Tape librarian/archive system 36 

65 Security alarm messages to a file. 36 

82 "Fast" delete for directory structures 36 

60 Enhance COPY to copy ACL's 35 

74 Printer problem warnings to users 33 

80 Command procedure capability in STB 32 

62 Enhance file access from user images 32 

5 Dependency networks for print and batch 31 

83 "Headers" and "footers" on printed outpu 31 

64 End-to-end encryption within DECnet-VAX 29 

66 DECnet proxy access for SET HOST command 28 


THE TOP 35 SIR'S AS RANKED BY 11/750 USERS 


Total ballots in this category: 200 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 115 

27 Remote printing of a LOCAL file 85 

28 Enforce expired password change 85 

20 Provide "date last read" for a file 81 

77 Individual field reports from AUTHORIZE 71 

1 Additional VAXcluster management tools 69 

71 Support BACKUP over DECnet. 64 

56 Display special characters in TPU 62 

57 Support ACL's on print and batch queues 59 

16 Queued requests for ALLOCATE command 57 

19 Standardize format for printable output. 54 

44 Internals and data structures documents 53 

51 Ability to re-start a process 52 

21 Support for simple project accounting. 45 

60 Enhance COPY to copy ACL's 44 

24 Installable memory resident images 43 

35 More system information on open files 40 

74 Printer problem warnings to users 38 

49 Determine the source of LAT terminals. 37 

17 Tape automatic volume recognition 35 

6 More detail in VMS accounting records 34 

76 Terminal server accounting info 33 

48 Provide disk arm information 32 

2 Better SYSUAF.DAT cluster support 31 

47 Tape librarian/archive system 31 

12 Improve form name/number displays 31 

4 Abbreviated commands in DTR 31 

80 Command procedure capability in STB 31 

79 Boot STB from tape drive 29 

43 2-way inter-process comm driver 29 

9 Improve VMS Mount service messages 28 

66 DECnet proxy access for SET HOST command 28 

62 Enhance file access from user images 27 

32 Mechanism to ignore ZERO LENGTH FILES. 27 

82 "Fast" delete for directory structures 27 
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THE TOP 35 SIR'S AS RANKED BY 11/730 and 11/725 USERS 


Total ballots in this category: 80 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 47 

27 Remote printing of a LOCAL file 41 

28 Enforce expired password change 33 

71 Support BACKUP over DECnet. 32 

20 Provide "date last read" for a file 29 

51 Ability to re-start a process 28 

1 Additional VAXcluster management tools 28 

44 Internals and data structures documents 23 

56 Display special characters in TPU 21 

77 Individual field reports from AUTHORIZE 21 

49 Determine the source of LAT terminals. 20 

16 Queued requests for ALLOCATE command 17 

19 Standardize format for printable output. 17 

2 Better SYSUAF.DAT cluster support 17 

57 Support ACL's on print and batch queues 17 

43 2-way inter-process comm driver 17 

76 Terminal server accounting info 17 

24 Installable memory resident images 17 

82 "Fast" delete for directory structures 17 

6 More detail in VMS accounting records 16 

60 Enhance COPY to copy ACL's 16 

4 Abbreviated commands in DTR 15 

21 Support for simple project accounting. 15 

80 Command procedure capability in STB 15 

74 Printer problem warnings to users 15 

73 Additional file attributes in BACKUP 14 

48 Provide disk arm information 13 

83 "Headers" and "footers" on printed outpu 13 

3 Process swapping between nodes 12 

7 Better terminal-sprinter support 12 

72 Provide "help line" support 11 

42 Run-time library routine to purge files 11 

45 Provide non-HSC volume shadowing. 11 

35 More system information on open files 11 

30 Additional TOPS compatibility features 10 
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THE TOP 35 SIR'S AS RANKED BY MicroVAX USERS 


Total ballots in this category: 192 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 114 

27 Remote printing of a LOCAL file 105 

71 Support BACKUP over DECnet. 82 

1 Additional VAXcluster management tools 75 

28 Enforce expired password change 73 

20 Provide "date last read" for a file 69 

77 Individual field reports from AUTHORIZE 62 

51 Ability to redstart a process 54 

16 Queued requests for ALLOCATE command 52 

56 Display special characters in TPU 52 

57 Support ACL's on print and batch queues 52 

44 Internals and data structures documents 52 

49 Determine the source of LAT terminals. 52 

76 Terminal server accounting info 46 

21 Support for simple project accounting. 44 

6 More detail in VMS accounting records 43 

19 Standardize format for printable output. 42 

43 2-way inter-process comm driver 41 

17 Tape automatic volume recognition 40 

9 Improve VMS Mount service messages 38 

24 Installable memory resident images 37 

2 Better SYSUAF.DAT cluster support 35 

64 End-to-end encryption within DECnet-VAX 34 

80 Command procedure capability in STB 33 

60 Enhance COPY to copy ACL's 30 

18 Provide a BACKUP/OPERATOR capability. 30 

35 More system information on open files 28 

47 Tape librarian/archive system 26 

65 Security alarm messages to a file. 26 

4 Abbreviated commands in DTR 26 

74 Printer problem warnings to users 24 

36 LEXICAL to return process identifiers 24 

66 DECnet proxy access for SET HOST command 23 

7 Better terminal-printer support 23 

12 Improve form name/number displays 23 
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THE TOP 35 SIR* s AS RANKED BY BUSINESS EDP USERS 


Total ballots in this category: 126 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 66 

28 Enforce expired password change 63 

77 Individual field reports from AUTHORIZE 61 

27 Remote printing of a LOCAL file 53 

1 Additional VAXcluster management tools 49 

20 Provide "date last read" for a file 49 

71 Support BACKUP over DECnet. 44 

51 Ability to redstart a process 37 

57 Support ACL's on print and batch queues 35 

44 Internals and data structures documents 34 

49 Determine the source of LAT terminals. 31 

4 Abbreviated commands in DTR 31 

76 Terminal server accounting info 31 

56 Display special characters in TPU 31 

16 Queued requests for ALLOCATE command 29 

19 Standardize format for printable output. 28 

24 Installable memory resident images 27 

35 More system information on open files 26 

17 Tape automatic volume recognition 25 

7 Better terminal-printer support 24 

2 Better SYSUAF.DAT cluster support 23 

6 More detail in VMS accounting records 22 

60 Enhance COPY to copy ACL's 21 

80 Command procedure capability in STB 21 

47 Tape librarian/archive system 20 

74 Printer problem warnings to users 20 

5 Dependency networks for print and batch 20 

8 SHOW QUEUE/BRIEF should display forms 20 

66 DECnet proxy access for SET HOST command 20 

58 Enhance DECnet remote file access 19 

21 Support for simple project accounting. 19 

82 "Fast" delete for directory structures 13 

79 Boot STB from tape drive 17 

22 SET HOST/DTE command procedure support 16 

10 Provide a fast file scan. 16 
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THE TOP 35 SIR'S AS RANKED BY SOFTWARE DEVELOPERS 


Total ballots in this category: 274 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 161 

27 Remote printing of a LOCAL file 122 

28 Enforce expired password change 120 

20 Provide "date last read" for a file 107 

1 Additional VAXcluster management tools 98 

77 Individual field reports from AUTHORIZE 97 

71 Support BACKUP over DECnet. 94 

56 Display special characters in TPU 85 

51 Ability to redstart a process 84 

57 Support ACL's on print and batch queues 79 

16 Queued requests for ALLOCATE command 72 

49 Determine the source of LAT terminals. 69 

44 Internals and data structures documents 67 

19 Standardize format for printable output. 64 

21 Support for simple project accounting. 61 

76 Terminal server accounting info 55 

24 Installable memory resident images 54 

60 Enhance COPY to copy ACL's 51 

2 Better SYSUAF.DAT cluster support 49 

9 Improve VMS Mount service messages 46 

80 Command procedure capability in STB 46 

4 Abbreviated commands in DTR 45 

35 More system information on open files 44 

17 Tape automatic volume recognition 44 

74 Printer problem warnings to users 44 

18 Provide a BACKUP/OPERATOR capability. 42 

6 More detail in VMS accounting records 42 

83 "Headers" and "footers" on printed outpu 42 

82 "Fast" delete for directory structures 41 

43 2 a way inter-process comm driver 41 

65 Security alarm messages to a file. 39 

43 Provide disk arm information 38 

47 Tape librarian/archive system 37 

12 Improve form name/number displays 35 

62 Enhance file access from user images 34 
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THE TOP 35 SIR 1 S AS RANKED BY EDUCATIONAL USERS 


THE TOP 35 SIR'S AS RANKED BY COMPUTER SCI. RESEARCHERS 


Total ballots in this category: 62 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 37 

20 Provide "date last read" for a file 33 

28 Enforce expired password change 33 

71 Support BACKUP over DECnet. 24 

57 Support ACL's on print and batch queues 22 

27 Remote printing of a LOCAL file 22 

77 Individual field reports from AUTHORIZE 22 

16 Queued requests for ALLOCATE command 20 

76 Terminal server accounting info 19 

6 More detail in VMS accounting records 19 

1 Additional VAXcluster management tools 18 

2 Better SYSUAF.DAT cluster support 17 

82 "Fast" delete for directory structures 17 

17 Tape automatic volume recognition 15 

21 Support for simple project accounting. 15 

35 More system information on open files 14 

60 Enhance COPY to copy ACL's 14 

49 Determine the source of LAT terminals. 13 

44 Internals and data structures documents 13 

73 Additional file attributes in BACKUP 13 

4 Abbreviated commands in DTR 12 

9 Improve VMS Mount service messages 12 

68 Password setting in groups 12 

51 Ability to re-start a process 12 

8 SHOW QUEUE/BRIEF should display forms 11 

18 Provide a BACKUP/OPERATOR capability. 11 

74 Printer problem warnings to users 11 

47 Tape librarian/archive system 10 

75 Queue name language/utility recognition 9 

62 Enhance file access from user images 9 

64 End-to-end encryption within DECnet u VAX 9 

40 System service to flush accounting 9 

72 Provide "help line" support 8 

36 LEXICAL to return process identifiers 8 

65 Security alarm messages to a file. 8 


Total ballots in this category: 49 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 35 

20 Provide "date last read" for a file 27 

28 Enforce expired password change 25 

77 Individual field reports from AUTHORIZE 24 

71 Support BACKUP over DECnet. 23 

27 Remote printing of a LOCAL file 23 

51 Ability to re-start a process 20 

57 Support ACL's on print and batch queues 15 

2 Better SYSUAF.DAT cluster support 14 

76 Terminal server accounting info 14 

6 More detail in VMS accounting records 14 

17 Tape automatic volume recognition 13 

44 Internals and data structures documents 13 

47 Tape librarian/archive system 13 

21 Support for simple project accounting. 13 

16 Queued requests for ALLOCATE command 12 

9 Improve VMS Mount service messages 12 

1 Additional VAXcluster management tools 11 

43 2-way inter-process comm driver 11 

19 Standardize format for printable output. 11 

82 "Fast" delete for directory structures 11 

49 Determine the source of LAT terminals. 10 

58 Enhance DECnet remote file access 10 

75 Queue name language/utility recognition 9 

35 More system information on open files 9 

73 Additional file attributes in BACKUP 9 

74 Printer problem warnings to users 9 

65 Security alarm messages to a file. 8 

56 Display special characters in TPU 8 

72 Provide "help line" support 7 

40 System service to flush accounting 7 

42 Run-time library routine to purge files 7 

60 Enhance COPY to copy ACL's 7 

64 End-to-end encryption within DECnet-VAX 7 

18 Provide a BACKUP/OPERATOR capability. 7 
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THE TOP 35 SIR'S AS RANKED BY DATA ACQUISITION/CONTROL USERS 


Total ballots in this category: 89 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 51 

27 Remote printing of a LOCAL file 49 

28 Enforce expired password change 41 

71 Support BACKUP over DECnet. 36 

20 Provide "date last read" for a file 34 

51 Ability to redstart a process 33 

1 Additional VAXcluster management tools 30 

77 Individual field reports from AUTHORIZE 29 

16 Queued requests for ALLOCATE command 22 

24 Installable memory resident images 21 

19 Standardize format for printable output. 21 

49 Determine the source of LAT terminals. 21 

44 Internals and data structures documents 20 

74 Printer problem warnings to users 20 

56 Display special characters in TPU 20 

60 Enhance COPY to copy ACL's 19 

2 Better SYSUAF.DAT cluster support 19 

43 2-way inter^process comm driver 18 

57 Support ACL's on print and batch queues 18 

82 "Fast" delete for directory structures 18 

79 Boot STB from tape drive 17 

21 Support for simple project accounting. 17 

3 Process swapping between nodes 16 

9 Improve VMS Mount service messages 16 

62 Enhance file access from user images 15 

48 Provide disk arm information 14 

66 DECnet proxy access for SET HOST command 14 

76 Terminal server accounting info 14 

10 Provide a fast file scan. 13 

83 "Headers" and "footers" on printed outpu 13 


42 Run^time library routine to purge files 12 

7 Better terminal*printer support 12 

32 Mechanism to ignore ZERO LENGTH FILES. 12 

6 More detail in VMS accounting records 11 

30 Additional TOPS compatibility features 11 


THE TOP 35 SIR'S AS RANKED BY CAD/CAM USERS 


Total ballots in this category: 76 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 45 

27 Remote printing of a LOCAL file 43 

71 Support BACKUP over DECnet. 35 

20 Provide "date last read" for a file 34 

1 Additional VAXcluster management tools 34 

28 Enforce expired password change 32 

77 Individual field reports from AUTHORIZE 32 

49 Determine the source of LAT terminals. 30 

2 Better SYSUAF.DAT cluster support 24 

51 Ability to redstart a process 24 

76 Terminal server accounting info 23 

57 Support ACL's on print and batch queues 23 

16 Queued requests for ALLOCATE command 19 

21 Support for simple project accounting. 18 

56 Display special characters in TPU 18 

44 Internals and data structures documents 16 

47 Tape librarian/archive system 16 

19 Standardize format for printable output. 16 

9 Improve VMS Mount service messages 15 

83 "Headers" and "footers" on printed outpu 15 

58 Enhance DECnet remote file access 13 

65 Security alarm messages to a file. 13 

6 More detail in VMS accounting records 13 

24 Installable memory resident images 12 

35 More system information on open files 11 

3 Process swapping between nodes 11 

60 Enhance COPY to copy ACL's 11 

82 "Fast" delete for directory structures 11 

22 SET HOST/DTE command procedure support 11 

75 Queue name language/utility recognition 10 

15 Enhance callable operator messaging rtn 10 

43 2*way inter“process comm driver 10 

23 Time out mechanism for $REQUEST/REPLY 10 

74 Printer problem warnings to users 10 

4 Abbreviated commands in DTR 9 
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THE TOP 35 SIR'S AS RANKED BY SERVICE BUREAU OPERATORS 


Total ballots in this category: 19 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

51 Ability to re-start a process 8 

26 Command line editing for long commands 7 

28 Enforce expired password change 7 

20 Provide "date last read" for a file 7 

71 Support BACKUP over DECnet. 7 

19 Standardize format for printable output. 6 

79 Boot STB from tape drive 6 

47 Tape librarian/archive system 5 

16 Queued requests for ALLOCATE command 5 

35 More system information on open files 5 

44 Internals and data structures documents 5 

80 Command procedure capability in STB 5 

1 Additional VAXcluster management tools 4 

18 Provide a BACKUP/OPERATOR capability. 4 

6 More detail in VMS accounting records 4 

77 Individual field reports from AUTHORIZE 4 

43 2^way inter*-process comm driver 4 

7 Better terminal-printer support 4 

5 Dependency networks for print and batch 3 

49 Determine the source of LAT terminals. 3 

32 Mechanism to ignore ZERO LENGTH FILES. 3 

62 Enhance file access from user images 3 

21 Support for simple project accounting. 3 

74 Printer problem warnings to users 3 

4 Abbreviated commands in DTR 3 

27 Remote printing of a LOCAL file 3 

45 Provide non-^HSC volume shadowing. 3 

9 Improve VMS Mount service messages 2 

54 Enhance line number support 2 

56 Display special characters in TPU 2 

57 Support ACL's on print and batch queues 2 

10 Provide a fast file scan. 2 

63 Mandatory security controls in VMS. 2 

64 End-^to^end encryption within DECnet^VAX 2 

65 Security alarm messages to a file. 2 
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THE TOP 35 SIR'S AS RANKED BY HARDWARE DEVELOPERS 


Total ballots in this category: 34 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 21 

27 Remote printing of a LOCAL file 19 

20 Provide "date last read" for a file 17 

71 Support BACKUP over DECnet. 14 

19 Standardize format for printable output. 11 

77 Individual field reports from AUTHORIZE 11 

44 Internals and data structures documents 10 

49 Determine the source of LAT terminals. 10 

51 Ability to re-start a process 10 

16 Queued requests for ALLOCATE command 10 

28 Enforce expired password change 10 

57 Support ACL's on print and batch queues 9 

1 Additional VAXcluster management tools 8 

60 Enhance COPY to copy ACL's 8 

24 Installable memory resident images 8 

56 Display special characters in TPU 8 

54 Enhance line number support 7 

21 Support for simple project accounting. 7 

43 2-way inter-process comm driver 7 

17 Tape automatic volume recognition 7 

7 Better terminal^printer support 7 

6 More detail in VMS accounting records 7 

32 Mechanism to ignore ZERO LENGTH FILES. 6 

36 LEXICAL to return process identifiers 6 

4 Abbreviated commands in DTR 6 

22 SET HOST/DTE command procedure support 6 

65 Security alarm messages to a file. 6 

9 Improve VMS Mount service messages 6 

30 Additional TOPS compatibility features 6 

80 Command procedure capability in STB 6 

58 Enhance DECnet remote file access 5 

2 Better SYSUAF.DAT cluster support 5 

62 Enhance file access from user images 5 

63 Mandatory security controls in VMS. 5 

3 Process swapping between nodes 5 
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Spring 1987 SIR Ballot Results 


THE TOP 35 SIR’S AS RANKED BY SCIENTIFIC/ENGINEERING USERS 
Total ballots in this category: 230 Spring 1987 Ballot 


SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 140 

27 Remote printing of a LOCAL file 115 

28 Enforce expired password change 96 

20 Provide "date last read" for a file 94 

71 Support BACKUP over DECnet. 89 

51 Ability to redstart a process 80 

77 Individual field reports from AUTHORIZE 76 

1 Additional VAXcluster management tools 72 

57 Support ACL's on print and batch queues 69 

16 Queued requests for ALLOCATE command 68 

56 Display special characters in TPU 62 

21 Support for simple project accounting. 62 

49 Determine the source of LAT terminals. 61 

19 Standardize format for printable output. 58 

44 Internals and data structures documents 58 

9 Improve VMS Mount service messages 50 

24 Installable memory resident images 49 

76 Terminal server accounting info 47 

2 Better SYSUAF.DAT cluster support 45 

17 Tape automatic volume recognition 44 

18 Provide a BACKUP/OPERATOR capability. 42 

6 More detail in VMS accounting records 41 

82 "Fast" delete for directory structures 40 

60 Enhance COPY to copy ACL’s 39 

47 Tape librarian/archive system 37 

74 Printer problem warnings to users 36 

83 "Headers" and "footers" on printed outpu 36 

35 More system information on open files 34 

43 2->way inter-process comm driver 33 

62 Enhance file access from user images 33 

65 Security alarm messages to a file. 33 

4 Abbreviated commands in DTR 32 

80 Command procedure capability in STB 32 

42 Run-time library routine to purge files 30 

79 Boot STB from tape drive 28 


THE TOP 35 SIR’S AS RANKED BY OFFICE AUTOMATION USERS 

Total ballots in this category: 141 Spring 1987 Ballot 


SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 90 

27 Remote printing of a LOCAL file 69 

28 Enforce expired password change 63 

77 Individual field reports from AUTHORIZE 63 

20 Provide "date last read" for a file 61 

71 Support BACKUP over DECnet. 55 

1 Additional VAXcluster management tools 53 

57 Support ACL's on print and batch queues 49 

49 Determine the source of LAT terminals. 43 

56 Display special characters in TPU 41 

51 Ability to re-start a process 41 

76 Terminal server accounting info 35 

19 Standardize format for printable output. 35 

6 More detail in VMS accounting records 33 

16 Queued requests for ALLOCATE command 32 

24 Installable memory resident images 30 

4 Abbreviated commands in DTR 29 

44 Internals and data structures documents 29 

2 Better SYSUAF.DAT cluster support 29 

9 Improve VMS Mount service messages 27 

35 More system information on open files 26 

21 Support for simple project accounting. 25 

17 Tape automatic volume recognition 24 

79 Boot STB from tape drive 22 

74 Printer problem warnings to users 21 

43 2^way inter-process comm driver 21 

80 Command procedure capability in STB 21 

22 SET HOST/DTE command procedure support 20 

12 Improve form name/number displays 20 

7 Better terminal-printer support 20 

60 Enhance COPY to copy ACL's 19 

65 Security alarm messages to a file. 18 

64 End*to*end encryption within DECnet-VAX 17 

36 LEXICAL to return process identifiers 17 

75 Queue name language/utility recognition 16 
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THE TOP 35 SIR'S AS RANKED BY TELECOMMUNICATIONS USERS 


Total ballots in this category: 75 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 36 

20 Provide "date last read" for a file 31 

77 Individual field reports from AUTHORIZE 31 

28 Enforce expired password change 29 

1 Additional VAXcluster management tools 29 

51 Ability to redstart a process 28 

27 Remote printing of a LOCAL file 28 

44 Internals and data structures documents 26 

71 Support BACKUP over DECnet. 25 

57 Support ACL's on print and batch queues 23 

16 Queued requests for ALLOCATE command 20 

6 More detail in VMS accounting records 20 

76 Terminal server accounting info 19 

21 Support for simple project accounting. 18 

9 Improve VMS Mount service messages 17 

49 Determine the source of LAT terminals. 15 

35 More system information on open files 15 

19 Standardize format for printable output. 15 

17 Tape automatic volume recognition 14 

56 Display special characters in TPU 14 

24 Installable memory resident images 13 

74 Printer problem warnings to users 13 

47 Tape librarian/archive system 12 

62 Enhance file access from user images 12 

64 End^to^end encryption within DECnet»VAX 12 

65 Security alarm messages to a file. 12 

60 Enhance COPY to copy ACL's 11 

22 SET HOST/DTE command procedure support 11 

2 Better SYSUAF.DAT cluster support 11 

7 Better terminal-printer support 11 

82 "Fast" delete for directory structures 11 

15 Enhance callable operator messaging rtn 10 

43 2*way interprocess comm driver 10 

58 Enhance DECnet remote file access 10 

79 Boot STB from tape drive 10 
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THE TOP 35 SIR'S AS RANKED BY OTHER 


Total ballots in this category: 20 Spring 1987 Ballot 

SIR SIR Total 

No. Description Votes 

26 Command line editing for long commands 12 

1 Additional VAXcluster management tools 9 

28 Enforce expired password change 9 

27 Remote printing of a LOCAL file 8 

20 Provide "date last read" for a file 8 

4 Abbreviated commands in DTR 7 

21 Support for simple project accounting. 6 

6 More detail in VMS accounting records 6 

71 Support BACKUP over DECnet. 6 

77 Individual field reports from AUTHORIZE 6 

51 Ability to redstart a process 5 

57 Support ACL's on print and batch queues 5 

67 Lexical for getting RIGHTSLIST info 5 

45 Provide non^HSC volume shadowing. 5 

76 Terminal server accounting info 5 

49 Determine the source of LAT terminals. 5 

59 Secondary passwords for DECnet ACS's 4 

22 SET HOST/DTE command procedure support 4 

5 Dependency networks for print and batch 4 

72 Provide "help line" support 4 

35 More system information on open files 4 

43 2-way inter“process comm driver 4 

15 Enhance callable operator messaging rtn 3 

23 Time out mechanism for $REQUEST/REPLY 3 

24 Installable memory resident images 3 

17 Tape automatic volume recognition 3 

18 Provide a BACKUP/OPERATOR capability. 3 

64 End*to*end encryption within DECnet-VAX 3 

65 Security alarm messages to a file. 3 

19 Standardize format for printable output. 3 

33 Provide full name in MAIL 3 

34 Full name translation of DCL files 3 

3 Process swapping between nodes 3 

8 SHOW QUEUE/BRIEF should display forms 3 

83 "Headers" and "footers" on printed outpu 3 
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A SIG Information Interchange 

A form for INPUT/OUTPUT submissions is available at the back of 
the issue. 

To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with 
the username PAGESWAPPER. 


Note 511.2 Access to USENET from VMS system 2 of 5 

"MARK S KRUEGER" 10 lines 3*»MAR-1987 19:08 

Can't wait to get my hands on the tape! >* 

Just wanted to keep the Usenet access from VMS thread alive! 
We're VERY interested in such software, and would be very glad 
to serve as a trial site. 

We may be able to chip in some programming assistance too. 

Didn't have a chance to get to San Francisco, but will be at 
Nashville. Will the Usenet working group meet there? 

anxious to get my hands on the software!... - Mark 

MARK S KRUEGER 

CALIFORNIA UNIVERSITY OF PENN 
COMPUTER CENTER 
CALIFORNIA PA 15419 
412/938-4030 
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Note 511.3 Access to USENET from VMS system 3 of 5 
"Jamie Hanrahan" 38 lines 3 J MAR^1987 19:57 

-< we're still here >- 

The effort is still alive. In San Francisco we agreed on a 
basic design and identified a few people who were willing to 
work on it. Since then it has suffered the same fate as many 
other projects to be done in my "copious free time", but 
progress is being made. I have autodial batch-mode file 
transfer using C-Kermit working; the next step is to add a mail 
interface with multihop forwarding. Netnews comes last. 
Somewhere in there we also need to write or acquire the "sliding 
window" extensions to OKermit, improve its autodial code to 
allow for the DMF32 problem, and make it more reliable under 
VMS. We also need to build stuff that'll run on Unix and talk 
to us with C*Kermit; at that point we'll just be more nodes on 
the Unix-based net. 

News promises to be a large can of worms. I have the source for 
the latest version of Netnews and am told that it will compile 
under VMS (I wasn't told anything about whether it would 
actually *run*, of course...). But the person who gave it to me 
(who has been doing some of the more recent maintenance work on 
it) doesn't recommend using it as a base. "It's a hack, a bad 
hack at that, and hopelessly over-complicated," he says. I've 
looked at it and I agree; I also have some ideas for how news 
could be handled much better on VMS systems, while maintaining 
compatibility with the existing stuff... 

..on the other hand, it's already written. 

Let's see, Nashville is "eight weeks away. We definitely won't 
have anything on the SIG tape, but we should be able to talk 
about some real results. 

Our Working Group Meeting is not on the schedule in the 
preliminary program (in fact, NONE of the sessions I submitted 
at the scheduling meeting in San Francisco were used. I thought 
working group meetings couldn't be turned down? Maybe they 
don't like me). Oh well, we can schedule the meeting on site, I 
guess. 
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See you there, and thanks for the offer of help. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 


Note 511.4 Access to USENET from VMS system 4 of 5 

"MARK S KRUEGER" 15 lines 10<-MAR*1987 18: 57 

At Nashville then... >- 

I've never been to a DECUS symposium before, so I just want to 
make sure I don't miss you guys. Is there some place I should 
look for a notice on where to find you? 

We're a small university site with a 780 and MicroVAX II for 
academic computing (both running VMS). I'm system 
manager/programmer/etc. 

We have one faculty member in particular who's a unix guru, and 
has suffered along so far with SW^TOOLS. He's got unix systems 
of his own at home, so he's on Usenet, but it's too costly for 
netnews. He'd be VERY happy to help out. 

We've got other faculty who want access to BITNET, etc. for 
research, and we hope that Usenet will be the answer. 

MARK S KRUEGER 

CALIFORNIA UNIVERSITY OF PENN 
COMPUTER CENTER 
CALIFORNIA PA 15419 
412/938*4030 
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Note 511.5 Access to USENET from VMS system 5 of 5 

"Jamie Hanrahan" 12 lines 11*MAR^1987 16:09 

*< look for the daily newsletter >- 

Watch the update.daily (a daily newsletter; thousands of copies 
will be distributed each morning) for both an article about the 
group and notice of the working group meeting. We did not 

schedule a regular session because there isn't that much in the 
way of results to talk about yet... next fall in Anaheim, 

though, we should be able to pat ourselves on the back (only two 
years after the first impromptu gathering... sigh.) and 

announce that we're up and running. 

EVERYONE, please have your Unix/netnews gurus examine my 

previous message re. implementation strategies. I'm interested 
in feedback! 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619^565-1865 


Note 539.6 suppressing an error message in DCL 6 of 6 

"Jamie Hanrahan" 16 lines 25-FEB* i 1987 16:23 

-< facility, severity, etc. fields are useful >- 

> I use the SET MESSAGE command in my login.com to 

> keep the error messages down to something that I 

> can understand. 

Suppressing the ident portion makes sense if you're not a 
programmer (if you are, the ident portion is the same as the 
suffix of the symbolic names of the form facility$_ident which 
your program should be checking for), but why the facility and 
severity? It's useful to know what component of VMS reported 
the error, and whether the error was considered fatal, warning, 
etc. How hard is it to find the text in the message even if all 
four parts of the message are present? 
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In my opinion, the more you try to change VMS to make it "easier 
to use", the less you will learn, and the more you will be 
hampered later on. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619^565^1865 


Note 548.3 Disc Corruption Problem 3 of 3 

"John Saunders" 16 lines 25-MAR*1987 22:24 

**< "Better late than never" >*■* 

I have trouble believing this is related, but we have had 
several episodes of disc corruption on our MicroVAX II. The 
item in this note which rings a bell is the correlation with 
system crashes: several of the episodes were noticed 

immediately after rebooting the system. 

Our symptoms also appear to be somewhat different. We were 
experiencing files containing all zeros, files which seemed to 
contain images of memory, and, most striking, files which 
contained a "disk test pattern": 55555555 AAAAAAAA repeated 
through each block until the last 16 bytes, which were more 
random. 

Field service replaced just about everything but the backplane 
(which is on order), but nothing helped. The problem seems to 
have disappeared with VMS V4.5, though, so maybe 4.3 was the 
problem. I don't know right now whether AUTOGEN changed our ACP 
parameters. 

John Saunders 
FEL Computing 
PO Box 72 

Williamsville, VT, 05362 
(802) 348-7171 


Note 560.8 DECnet Node Isolation Needed 8 of 11 

"Bob Hassinger" 15 lines 7^MAR^1987 16:24 

-< We need to connect to other nets * do you? >* 

Re need: DEC not withstanding, I see a need in my situation for 
the ability to interconnect nets - i.e. I want to talk to a 
system that is also in a whole different set of connections from 
mine. The key factor is that my system and theirs, as well as 
the the net they are on, are not managed or controlled by my 
organization. There are totally separate, and can not be 
considered "trusted" at all - i.e. a university network! 

It seems to me there are likely to be a growing number of people 
in the same situation as more and more of us develop nets and 
then a need to interconnect to each other outside our own 
organizations. Does anyone else see the same need? 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617-435-9061 


Note 560.9 DECnet Node Isolation Needed 9 of 11 

"John Osudar" 8 lines 10^MAR a 1987 21:54 

*< isolation/security IS needed! >* 

Are you talking about interconnecting DECnets or other types of 
networks -- it's not clear from your message... If you ARE 
talking about DECnets only, then you've hit upon one of the 
points I've been trying to make: not only is there a need for 
expanded addressing, there is also a (greater?) need for 
isolation/security, particularly in "unfriendly" or 

"non^cooperating" situations. The interim solution I proposed 
could be used unilaterally and could restrict external access to 
specific nodes on either side of the "bridge". 


John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A*051 
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Argonne, IL 60439-4837 
(312) 972-7505 


Note 560.10 DECnet Node Isolation Needed 10 of 11 

"Jamie Hanrahan" 19 lines ll-MAR-1987 16:31 

«-< it won't be all that secure >- 


I am talking about DECnets only (although there's no reason, 
other than complexity, why a full-blown DECnet-to-other_net 
gateway couldn't be implemented at this level, with some assist 
from an ACP; of course, if your two networks provide different 
capabilities, there will be problems mapping from one to the 
other) . 

I agree that there's a need for this sort of thing. But I 
caution that restricting all but a few nodes of the other guy's 
network from touching your network is no guarantee that you've 
isolated yourself from the untrusted nodes. One of the 
"untrusted" system managers could change their DECnet 
configuration data base so as to masquerade as one of the nodes 
you trust when the "real" trusted node is down. Routing- level 
passwords don't help, as these are visible throughout a network. 
The "area number mapper with address restriction" could protect 
you from casual access by untrusted nodes, but that's all. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 
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Note 560.11 DECnet Node Isolation Needed 11 of 11 

"Larry Kilgallen" 11 lines ll-MAR-1987 21:31 

-< Encryption is the key ("Red Eye of Love") >- 


In my opinion the only defense against the exposures Jamie 
outlined in .10 is encryption, with the keys never stored in a 
VMS-accessible location (the master keys, that is). Pair-wise 
master keys for every pair of nodes between which communication 
is allowed should be sufficient. 

Don't look for significant end-to-end encryption to happen soon, 
though. Time and time again when the security working group has 
put this question on the SIR ballot it has NOT made it anywhere 
near the top of the list. The user community has spoken, and 
from all appearances, DEC has listened. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


Note 564.2 SYNCHRONOUS AUTODIALING 2 of 5 

"keith Chambers" 4 lines 6-MAR-1987 13:43 

-< Try an asynchronous dialer... >- 


We have a DMR-11 that we autodial using an autodialer on an 
asynchronous line. The software turns the circuit on, sends the 
number to the autodialer, and then waits to make sure the 
circuit connected. 

keith Chambers 
General Electric 
Mail Drop D38-A 
P.0. Box 8106 
Charlottesville VA 22906 
(804)978-6132 
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Note 564.3 SYNCHRONOUS AUTODIALING 3 of 5 

"Jamie Hanrahan" 3 lines 6*MAR*1987 16:35 

fa < more info, please? >- 

So your autodialer has an async port, and the modem for the line 
it’s attached to has a sync port? What sort of hardware is 
that? Sounds vaguely related to the old Bell 801 setup. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 


Note 564.4 SYNCHRONOUS AUTODIALING 4 of 5 

"Jan C Ostendarp" 20 lines 27-MAR-1987 02:36 

*< M M MM}-}- }- }- >* 


Shot in the dark... (I'm a novice with communications and 
terminology). 

Racal«?Vadic has a modem, model 4850PA, which has built-in 
auto-dial. It has a single 25-ipin connector and operates in 
asynchronous and (bi?)synchronous modes. With default settings 
it holds DSR high to trick the software allowing output to get 
to the modem (i.e. dialing instructions). 

I've made use of the modem in a VAX 2780/3780 PE application 
which runs unattended in batch (nightly data transmission from 
IBM RJE) . The modem drops DSR for 4 seconds on disconnect so 
software is notified the line was dropped. It's connected to 
the VAX DUP-11 port (XJDRIVER?) but can also work the sync port 
on the DMF-32• Unfortunately, the driver for the DMF-32 sync 
port (XGDRIVER) doesn't monitor DSR continuously and frequently 
misses the 4 seconds pulse. 

Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
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Boston, MA 02116 


Note 566.2 Refusing VMS Subprocesses 2 of 2 

"Edgar Zamora" 7 lines 19-MAR-1987 15:16 

*< Re-using VMS Subprocesses >- 

We've written a simple routine, callable from high level 
languages, that spawns a subprocess to execute DCL commands. 
The subprocess "hangs around" until a LOGOUT string is passed to 
it. We did not use mailboxes because of terminal I/O problems; 
instead we used logicals. It's a little tricky, but it works. 
If you're interested, feel free to contact me. 

Edgar Zamora 

Manufacturers Hanover Trust Co. 

270 Park Ave., 

New York, NY 10017 
(212) 286-5279 


Note 567.6 BACKUP Hints and Questions 6 of 7 

"Bruce Bowler" 18 lines 17^MAR-1987 16:03 

*< SDI cable problem? >- 


Re: 567.4. After a month of running at default blocksize and 
with the new TA78, the problem mentioned re-occurred. Our local 
field service people spent lots of time on the phone with 
district and (i think) tape engineering. The eventual solution 
arrived at was to swith to shorter SDI cables, we were using 80 
foot cables, and since switching to 25 foot cables we have not 
had the problem in at least 3 situations were I wold have 
expected it to happen. 

The logic on this was that the K.STI in the HSC50 was not 
driving the signal lines with enough strength, or the receivers 
in the TA78 were a little hard of hearing. We have been through 
at least 5 different sets of these boards (both receivers and 
STI's) and as such it seems to me that if this is the case, it 
is a design problem rather than a bad component on one of the 
boards. Also I would expect that I am not alone in this 
predicament, but have heard of no other sites that are having 
similar problems. Are there other sites out there who have 
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TA78's and 80* SDI cables? If so lets here from you. 

Bruce Bowler 
General Electric 
1 River Road 
Bldg 2 Room 609 
Schenectady, NY 12345 


Note 567.7 BACKUP Hints and Questions 7 of 7 

"Lora Wether ill" 4 lines 26*MAR*1987 17:17 

-< /NOCRC on MICROVAX II >* 

Using /NOCRC on a MicroVAX II with RA disks to TK50 yielded 
results similar to Frank Nagy's... with disk half full: /NOCRC 
took 21 minutes less. On a MicroVAX with RA disks to TSV05 
(same disks): /NOCRC took 17 min less. 

Lora Wetherill 
P.0. Box 179 
Mail Stop 10096 
Denver, Colorado 80201 


Note 571.4 All-In^l 2.1 Looping Problems 4 of 5 

"Mark Oakley" 88 lines 2*MAR-1987 00:20 

-< All*In*l Looping Fix >** 

At last DEC All-In-1 support has provided a patch to the 
All-In-l looping problem. The patch is available from TSC in 
Atlanta. Below is DEC'S explanation of the problem and the fix: 

This patch is an attempt to fix the All^In-1 looping problem 
which is caused when FMS starts returning unexpected errors to 
All^In-l. We only know of one way to reproduce this problem (by 
doing a $SET TERM/PAGE=20 before entering All*In-l). We 
understand from problem reports, that a similar problem can be 
caused by detaching from an All*In«l process. 
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The problem happens if FMS somehow detects that it is unable to 
display a form. This can happen if 

4 The terminal characteristics are changed (EG: $SET 

TERM/PAGE=20) 

- a detached All*In-l process is triggered off by some 
event to do some work which causes FMS to do something. 


When FMS detects that it has been unable to display a form, it 
also decides that input from a non-existent form is not 
possible. Thus the FDV$_GET FMS call returns back an error 
status, which causes All*In-l to abort the current form and 
attempt to display the previous form. The menu stack is thus 
unwound till you get to the MAIN form, which is the first form. 
There are now no more forms to which All-In-1 can unwind to and 
it attempts to redisplay the current form and this triggers of 
the loop. 

All-In-1 attempts to display the form and then get input. The 
FDV$GET call returns an error, and All-Innl tries to unwind to 
the previous form. As we're at the MAIN form, there's nowhere 
All^-In-1 can unwind to, so All-In-1 tries to redisplay the 
current (MAIN) form and get input and now we're really looping! 
See flow diagram below: 

+*»+&******«***»*-*> Display form + 
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If you switch tracing on then you can actually see All^In^l 
winding back the menu stack and then start looping at the MAIN 
form. 

The only fix that we can do at present is to count the number of 
FMS errors that are given to us during a FDV$GET. If this 
number goes above a set limit (say 50) , then we drop out of 
AllMln^l by issuing a FATAL error. All^In^l cannot recover from 
errors that FMS has encountered, and it cannot display these 
errors either as that would require calling FMS routines which 
in itself would cause another loop cycle! 

The patch requires three modules: 

OAGBL.BLI ^ This has a new globally defined literal to hold the 
number of FMS errors that we’re prepared to tolerate. If 
you have customised your OAGBL.BLI, then you'll have to 

carry over this change to your OAGBL. 

OAGBL.OBJ * Compiled version of above in case customer has not 
customised OAGBL.BLI, and doesn't have a BLISS compiler. 
OAMESS • OBJ *4 Now contains an extra FMSERR Fatal error 
OAFMS• OBJ *4 Increments error count and drops out when count goes 
above limit set in OAGBL. 

Copy the above files onto your system. If you have customised 
your OAGBL.BLI, then do a difference against your version and 
make sure that you carry over your customisation to the new 

version. Compile OAGBL.BLI if you've customised it. If you 

haven't customised OAGBL.BLI, then you do not have to compile 

OAGBL.BLI. Replace all the objects in the OALIBR.OLB All*In*l 
library by using the command: 

LIBRARY/REPLACE/LOG OA$BUILD:OALIBR•OLB OAFMS.OBJ 
LIBRARY/REPLACE/LOG OA$BUILD:OALIBR.OLB OAGBL.OBJ 
LIBRARY/REPLACE/LOG OA$BUILD:OALIBR.OLB OAMESS.OBJ 

Now relink All^In^l (see System Managers Guide p 6^18 Sections 
1,2 and Installation Guide Chapter 2, steps 6 to 8 ) 

Mark Oakley 

Battelle Memorial Institute 
505 King Ave. 

Columbus, Ohio 43201-42693 
614/424^7154 
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Note 571.5 All^In^l 2.1 Looping Problems 5 of 5 

"Lora Wether ill" 3 lines 26*MAR31987 17:41 

a < OK, but... >* 

We have the same problem with A1 V2.1, but it ONLY occurs when 
using a spawned process under All-In** 1... and that doesn't seem 
to fit .4 ... perhaps we have another problem? 

Lora Wetherill 
P.0. Box 179 
Mail Stop 10096 
Denver, Colorado 80201 


Note 572.1 DECnet reporting routines 1 of 1 

"George Walrod" 26 lines 12*MAR i 4l987 15:26 

**< You had to Ask 

*<Don't Ask For Too Much >* 

There are two ways I know of. 

The first is an undocumented, unsupported QIO to the NETACP, 
through a Mailbox. Very Difficult!!! 

First assign a MAILBOX to the NET device. 

Then Issue QIOW with IOsFunc of IO$_ACPCONTROL with the Pi being 
a descriptor of Network Function Block(NFB) with a Length of 5 
and the Second Longword being the address of the NFB itself. 
The NFB should be 5 bytes long containing the Function code of 
NFB$C__READEVENT. The P3 parameter is Return Length of the 
event. The P4 parameter is Result Buffer Descriptor declared 
the follow first long being the length should be 
EVL$C__EVTBFRSIZE and the second longword address of buffer to 
hold the raw^event. This raw^event buffer should be at least 
EVL$C_EVTBFRSIZE bytes long. 

After the QIOW as completed the second word of the IOSB will 
contain the length move this to the first longword of rawSevent 
descriptor buffer. 
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Then just filter out the events you desire. 

The Second and Easiest way is to setup a Event Log file in the 
NCP, so all events will be logged this file. An run a command 
procedure or program to read the event log file and process the 
events you desire. 

George Walrod 
4260 A -b chain bridge rd 
fairfax, va 22030 


Note 574.2 Cluster time coordination. 2 of 7 

"James R. Ostrosky" 4 lines 19-MAR-1987 13:56 

-< Cluster time coordination >- 


The use of these command files for cluster time coordination 
looks really neat; one of those ideas that is simple and 
obvious; once someone else figures it out! Thanks much for this 
one; I will definitely be putting it to good use. 

James R. Ostrosky 
3910 OLD WM PENN HWY 
PITTSBURGH, PA 15235 


Note 574.3 Cluster time coordination. 3 of 7 

"Jamie Hanrahan" 39 lines 19-MAR k: 1987 20:11 

*< Who's afraid of a little DCL? >* 

This is a reply to 574.1 by Mr. Johnson: Don't be afraid of 
DCL for this application! We are talking about executing a mere 
handful of DCL commands, and the ones that take a long time (the 
OPEN on the remote task specification and subsequent creation of 
server process and connect confirm, i.e. OPEN SYS$NET) are not 
time-critical, since the time at the "master" node is sampled 
after the connect confirm. I doubt mightily that you could 
activate images on each side faster than DCL can WRITE and READ 
a single record through the DECnet logical link. (DCL OPEN, 
WRITE and READ don't invoke images.) 
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VMS does the right thing for existing TQEs when a SET TIME 
changes the time. Those originally requested with delta times 
are modified so that they still happen the correct number of 
ticks after the request; those originally requested with 
absolute times are left alone, so they come due at the original 
request time (albeit according to the new calibration) • 
(Internals manual. Paragraph 11.1.3.1, page 216.) 

If you are doing chargeback by wall^clock time, you have a 
problem. The $SETIME system service really should place an 
entry in the accounting file reflecting the change. Until it 
does, the best approach is a program which does a $SNDJBC with a 
SJC$_WRITE__ACCOUNTING function, followed by a $SETIME. 

In VMS 4.0 through 4.4 there was a problem in DECnet regarding 
timer requests. NETACP's timers ran off of absolute-timed TQEs 
instead of delta-timed, so if the system time was set back, all 
timer a invoked DECnet operations would cease until the new time 
caught up with the time at which the time was changed (according 
to the old time). These operations included the sending of 
HELLO-TEST messages, so that adjacent nodes would time out... 
(see the May 86 VAX/VMS Systems Dispatch, Seq. 25.5.14, page 
29). The problem was fixed in V4.5, according to the patch 
journal files. 

It is of course possible that other layered products, not to 
mention third-party and end-user-written software, might have 
similar glitches lurking. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 
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Note 574.4 Cluster time coordination. 4 of 7 

"Jan C Ostendarp" 8 lines 20-MAR-1987 19:19 

~< can proxy logins work here? >- 


Thanks for contributing this command procedure solution for 
clock synchronization. I'd like to avoid hardcoding the system 
password as well as putting the command procedure in the 
directory of the default decnet account (world write access and 
all that). Do proxy logins offer a solution for this concern? 
I'm using a cluster common sysuaf. I think netuaf is also in 
sys$common:[sysexe]. I'll give it shot... stay tuned. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 574.5 Cluster time coordination. 5 of 7 

"Jamie Hanrahan" 9 lines 20*MAR £4 1987 21: 54 

>-< proxies should work >- 


We're not running clusters, but these command procedures work 
just as well without them (time coordination is important on 
non- cluster DECnets as well) . I created a special account for 
the timekeeping function, with proxy access on the "master 
clock" machine. Remember that the batch job in the "slave" 

machine has to have OPER and LOG_IO privileges to do a SET TIME 

(in addition to NETMBX) . As for proxy logins on a cluster, 
seems to me that a cluster common NETUAF will work just as well 

as a cluster common SYSUAF -- but of course I have no way of 

knowing. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 
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Note 574.6 Cluster time coordination. 6 of 7 

"Jamie Hanrahan" 14 lines 20^MAR«1987 22:08 

fi < yet another addendum >*4 

You know, I *still* feel that the cluster time coordination 
problem should be solved in hardware, at least for debased 
clusters. If the CPUs are all close to each other, it ought to 
be possible to drive all of their interval and TOY clocks from a 
common oscillator. To eliminate single-point-of^failure, you 
could have dual redundant master clocks, and each of the CPU's 
clocks would be able to run on its own if the master signals 
weren't present. 

For applications that *really* need to know what time it is 
(aiming radiotelescopes, for instance), you could buy an 
upgraded master clock of whatever accuracy you could afford, all 
the way up to a WWVL receiver or cesium-beam clock (don't laugh; 
they're in the HP catalog (or used to be, anyway)). 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 


Note 574.7 Cluster time coordination. 7 of 7 

"Michael R. Pizolato" 12 lines 30*MAR*1987 14:57 

*< We don't use proxies. >* 

We don't use proxy logins, so I don't know if they would help. 
The reason we don't use proxies is because we have a huge 
network (you can't believe how huge this thing is), and our 
network administrators don't want to allow the following 
scenario: 

1. Node BIGVAX (an 8650) goes down. 
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2. Node SMLVAX (one of many MicroVAXes) reboots as node 
BIGVAX, thereby getting all of BIGVAX's proxy access. 


I'd be interested to know how the procedures work for you using 
proxies. 

Michael R. Pizolato 
AT&T Technology Systems 
Dept. 323610 
555 Union Blvd. 

Allentown, PA 18103 
215/439*5500 


Note 575.2 SET HOST/DTE blows up with data overrun 2 of 2 

"James L. Buckley" 17 lines 16*MAR-1987 11:45 

*< Try SYSGEN Darameter TTY ALTYPAHD >* 


I am currently using SET HOST/DTE to write this "NOTE" off of a 
750 very heavily loaded. I could only get this to work by 
increasing the SYSGEN parameter TTY__ALTYPAHD. The user in the 
previous reply was quite correct; SET HOST/DTE does in fact use 
only the TYPE_AHEAD buffer for receipt of data which can quickly 
load up input buffers. 

These buffer sizes were set up to handle keyboard input. 
Displaying full screen data at anything above 300 BAUD will 
require increasing the TTY__ALTYPAHD parameter. On the 750 this 
was set to 300 from a default of 200. Your performance may vary 
depending on your driving habits and road conditions. 

James L. Buckley 
COM/Electric Co. 

2421 Cranberry Hwy 
Wareham MA, 02571 
(617)^291*0950 x3224 


Note 577.15 Questions/Comments on TPU 15 of 16 

"Stuart Renes" 14 lines 11*MAR*1987 13:56 

*< CBI course for EVE >* 

For those of you interested in teaching your users about TPU f 
there is a DEC Ed Services CBI course available for EVE. I just 
got it last month. Look in your Ed Services catalog for 
details. The course is pretty good and someone can learn EVE in 
a couple of hours with this course. 

By the way, there are security risks with the use of previous 
releases of the CAI/CBI courses. This latest course kit 
includes a patch to resolve the issue. It seems that some VMS 
users will use their VMS password when asked to register for a 
course. THis goes in a file that was protected W:RWE. The 
patch allows the CAI modules to be installed so you can deny 
World access to the critical file. If you have CAI/CBI courses 
on your system, take notice. 

Stuart Renes 

AT&T Technologies, Inc. 

Mail Stop: 2793 
3000 Skyline Dr. 

Mesquite, TX 75149 
(214) 288*2286 


Note 577.16 Questions/Comments on TPU 16 of 16 

"Larry Kilgallen" 4 lines 11*MAR*1987 21:35 

*< Another strike(out) for secondary passwords’ >* 

It would seem the CBI developers are stuck in the same rut they 
have been in for 6 years. The least they could have done is 
check their secondary password and NOT ALLOW it to be set equal 
to the VMS password’ 


Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 
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Note 584.2 SET HOST/DTE woes. 2 of 4 

"James R. Ostrosky" 11 lines 19-MAR-1987 13:52 

*< SET HOST/DTE and MODEMS >* 


Note 584.4 SET HOST/DTE woes. 4 of 4 

"Michael R. Pizolato" 3 lines 30-MAR-1987 15:01 

*< I'll try it. >* 


There was a very obscure statement in one of the release notes 
that came with VMS, stating the problem with the DMF-32 and 
modems. This statement indicated that the DMF-32 will not 
recognize any incoming characters until Carrier Detect is seen. 
The work-around given was to scan the modem status word (via QIO 
and I0$_SENSEM0DE!I0$M_RD_M0DEM) and detect Carrier Detect 
automatically. The DTE__DF112 executable provided with VMS will 
not work. I have written an autodialer for the DF112 (and a DCL 
command DIAL) in Fortran-77, and they work just fine for us. 
NOTE: See 10 579.0 and 10 579.1 in relation to this one. 
Perhaps I should submit this to the Pageswapper... 

James R. Ostrosky 
3910 OLD WM PENN HWY 
PITTSBURGH, PA 15235 


Note 584.3 
"Jonathan M. 


SET HOST/DTE woes. 
Prigot" 7 lines 

-< Never overestimate! >- 


3 of 4 
21-MAR-1987 09:42 


I think I see two things: first, if memory serves, DTE_DF112 
must be INSTALLED like its DTE_DF03 forerunner. Second, and 
more important, neither DF03 nor DF112 programs provide the 

control that you think they should. That is, try changing your 

NUM:1234567 to NUM:T1234567# or NUM:P1234567# • The dialer 
modules only have the smarts to provide the *B wakeup and some 

LIMITED syntax checking of the number you provide. 

Jonathan M. Prigot 
W R Grace & Company 
55 Hayden Avenue 
Lexington MA 02173 
(617)861*6600 


I did INSTALL DTE__DF112, and it didn't help. However, I did not 
try changing the number in the way you said. I'll give it a 
try. Thanks! 

Michael R. Pizolato 
AT&T Technology Systems 
Dept. 323610 
555 Union Blvd. 

Allentown, PA 18103 
215/439-5500 


Note 585.3 Anyone use defragmentation programs? 3 of 4 

"Stuart Renes" 33 lines ll-MAR-1987 14:08 

~< Beware of defragmentation proqrams! >* 

I have been involved in the development of a 0DSM2 disk 
defragmentation product and will offer this advice. This 
particular type of program has more product liability than 
anything else I have personally seen in a long time. There are 
so many bad things that can happen to your ODS-2 disk files as a 
result of even the slightest bug in a defragmentation program, 
that EXTREME caution is the watchword. Most people don't trust 
them and wind up using them only after an IMAGE backup which 
negates most of the potential time savings. 

Some things to beware of: 

A good defragmentation program MUST not alter file-ids! 
Otherwise your batch and print jobs will abort (they use 
file-ids). 11/750's that try to boot Stand-alone Backup off 
disk will not be able to do that WITHOUT warning if the physical 
location of VMB.EXE is changed because your defragmentation 
program moved it during its contiguous file gathering process. 
That's because its physical location is written into the 
B00TBL0CK during the STABACKIT procedure. 
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(Yes, there IS a use for the BOOTBLOCK under VMS!!) 

There are many OTHER unexpected things that live under 0DSM2 
that DEC doesn't expect you to know or care about and they even 
change some things during VMS updates WITHOUT documenting them! 

So r if your defragmentation program works fine on VMS 

4.5,.that doesn't mean that when 4.6 arrives it will STILL 

work. 

I think I've said enough to get you to thinking! Remember, your 
0DS*2 disks are the heart of your system as far as your users 
are concerned. I'm not sure the possible time savings promised 
by these products are worth the damage that could creep in 
unnoticed until.! 

Stuart Renes 

AT&T Technologies, Inc. 

Mail Stop: 2793 
3000 Skyline Dr. 

Mesquite, TX 75149 
(214) 288*2286 


Note 589.6 VAXstar/uVAX2000 Announcement 6 of 6 

"Jack Patteeuw" 17 lines 17*MAR*1987 17:22 

-< Announcing the LN03R ! >* 

A LN03R is definitely a LN03 that does Postscript ! Check the 
latest Sales Update or the March 2, 1987 edition of the DEC U.S. 
Price Book. 

What, you don't have a price book ? The note inside mine says 
it's for sales reps "and customers", so ask your "order taker" 
for your own personal copy ! 

Most everyone knows that the LN03 family of laser printers is 
built off of a Ricoh copier engine. Ricoh now has a new engine 
(being used by TI and QMS) that is rated at 15 pages per minute 
and has two input trays. This certainly would make it the 
"top-of*the»line" in desktop laser printers. This is faster 
than the XEROX 2700 engine (which is used in the LN01 and has 
been the de*facto standard for years in the laser printer) which 
is rated at 12 pages per minute. 
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Could there be an LN05 (?) in the future ?!!! 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323*8643 


Note 590.2 VAX 11/750 Word Processor 2 of 2 

"Stuart Renes" 23 lines 12ftMAR*1987 14:02 

*< DECtype support woes >* 

We too use DECtype. It supports many users on an 11/785 without 
much overhead. Our secretarial staff love it because its so 
easy to learn. 

Unfortunately, DEC doesn't seem to want to support it anymore. 
There hasn't been another release in 2 years ft not even to fix 
the bugs that remain or crept in under DECtype 4.0 

DECtype has problems with LN03 printers * it seems to insert 
blank lines every page or so ft right in the middle of text. 

Also, you can tab outside the right margin if you use the 

rightsjustified tab stops and this causes DECtype to hang up 
when you try to print the document. 

DECtype 4.0 was supposed to support editing by document #, but 
it never made it into production * the document numbers are 
there in the index but no reference is made to them elsewhere. 

Anybody know what the future of DECtype is?? I've paid monthly 

software support for it for 2 years and received nothing (no 

answer yet to my SPR's either). 

Stuart Renes 

AT&T Technologies, Inc. 

Mail Stop: 2793 
3000 Skyline Dr. 

Mesquite, TX 75149 
(214) 288*2286 
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Note 592.4 ALL#IN#1/INGRES INTEGRATION 4 of 5 

"Jan C Ostendarp" 6 lines 24*MAR#1987 01:58 

#< TERM__INGRES identifies term type? >* 

Isn't the TERM_INGRES logical used to identify the terminal 
type? (i.e. define TERM_INGRES "VT100K"). I'm not aware of 
any special logical names which Ingres front#ends look for to 
route input and output. 

Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 593.3 Memory disk driver going away??? 3 of 7 

"Jan C Ostendarp" 5 lines 28*FEB#1987 18:42 

u < original article? memory disk drive. >4 

Can you refer me to the PAGESWAPPER article which describes how 
to use the unsupported memory disk driver? 

(sysgen,install,etc.) Thanks. 

Jan 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 592.5 ALL#IN#1/INGRES INTEGRATION 5 of 5 

"Lora Wether ill" 5 lines 26*MAR-*1987 17:32 

#< Yes., that's the trouble! ># 

Yes, that it exactly what it is used for, but if INGRES doesn't 
get a valid value for that logical, you CANNOT run INGRES. 
Somehow with INGRES running underneath All*In#l, that logical 
gets messed up and INGRES says that VT100K or VT100F is an 
invalid terminal type. 

Lora Wetherill 
P.0. Box 179 
Mail Stop 10096 
Denver, Colorado 80201 


Note 593.4 Memory disk driver going away??? 4 of 7 

"John Osudar" 2 lines 3*MAR*1987 19:28 

a< original article >4 

Page VAX-24 in the October 1986 newsletter contains the article 
on the memory disk driver. 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A*051 
Argonne, IL 60439*4837 
(312) 972*7505 
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Note 593.5 Memory disk driver going away??? 5 of 7 

"Stuart Renes" 13 lines 12*MAR*1987 14:07 

-< VAX Memory Disk available >- 


There is at least one small software house that sells a version 
of a VAX memory disk that outperforms what DEC did by 50 - 75%. 

It’s cheap and works well. Due to the commercialism policy I 
cant say anymore here. I'll be glad to talk about it offline. 

Hope this helps. 

Stuart Renes 

AT&T Technologies, Inc. 

Mail Stop: 2793 
3000 Skyline Dr. 

Mesquite, TX 75149 
(214) 288-2286 


Note 593.6 Memory disk driver going away??? 6 of 7 

"Mark Hartman" 4 lines 19 U MAR-1987 21:19 

~< What's wrong with both? >- 


I don't see why we shouldn't be able to have both disk file 
cacheing AND the memory disk. Other DEC operating systems do 
(i.e., RSTS, and we all know how much Engineering hates RSTS), 
so why not let the "flagship" 0/S have both? 

Mark Hartman 
Jadtec Computer Group 
546 W Katella Ave 
Orange CA 92667 
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Note 593.7 Memory disk driver going away??? 7 of 7 

"John Saunders" 5 lines 22*-MAR*1987 07:02 

^-< Both would be fine 


At our site, we using (trying to use) a MicroVAX II for software 
product development. We use the PDDRIVER for program listings, 
and anything else which is temporary. MicroVAX memory is cheap, 
MicroVAX disks are not. Disk caching would help to speed disk 
access, but would not solve our temporary file problem. 

John Saunders 
FEL Computing 
PO Box 72 

Williamsville, VT, 05362 
(802) 348-7171 


Note 595.1 Calling a WOMBAT Wizards 1 of 2 

"Bob Hassinger" 8 lines 7-MAR-1987 16:37 

-< Consider a program if all else fails... >~ 


I am sure the true wizards know how, after all you can do just 
about anything in DTR! I do not happen to know off hand 
however. My experience is that in a situation like this it can 
be a valuable learning experience to work it out, no matter how 
long it takes or how slow the result is. However, sometimes the 
cost (time) effective answer for me turns out to be a five or 
ten line program in FORTRAN, BASIC or whatever. Keep this 
option in mind. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617*435*9061 
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Note 595.2 Calling a WOMBAT Wizards 2 of 2 

"Jack Patteeuw" 18 lines 9*MAR^1987 07:57 

-< It* s in the book ... !!! >*■ 


After reading through some back issues of the "Wombat Examiner" 
and more closely examining the documentation I found out that it 
is possible to "extend" Datatrieve with user written functions 

i i 

The problem mentioned in .0 is really trivial to solve with a 
program (we used VAX C) but the trick is understanding how DTR 
is passing parameters to you and how it wants them back. It was 
really "wild" linking the DEBUGger into DTR and then walking 
through all the routines (like "Trash Registers") until we got 
to our routine. 

The only problem we had was reading the documentation close 
enough to understand that that what DTR passed to us for 
return string descriptor was a "dynamic" string descriptor, 
quick call to STR$GET1_DX to get one and we were all set. 

Part of the credit goes to Dan Lanphear my new "Rent^a^DECie" 
who, although not yet at "Wombat Wizard" status, certainly does 
know his VMS !! 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313-023-8643 
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Note 597.0 Having your VAX call you back 3 replies 

"Dan Shoop" 13 lines 26-;FEB-1987 13:35 


Since it's a long distance call from my house to work, I'd like 
the ability to have my VAX call me back. I know someone 
mentioned how to do this a few years ago. 

Any ideas? 

Dan Shoop Citicorp 11th Floor 575 Lexington Ave NY NY 10043 
212.906.2403 

Dan Shoop 

11th Floor Datacenter 
Citicorp Credit Services 
575 Lexington Ave 
New York, New York 10043 
212 906 2403 


Note 597.1 Having your VAX call you back 1 of 3 

"Joel Gallun" 4 lines 27-FEB*1987 17:26 

-»< call-back program >~ 


We have a utility that does that here at Goddard Space Flight 
Center. I will speak to the person who developed it and see if 
he would be willing to release it to you, unsupported, as^is, 
etc. I'll reply to this message again later when I know more. 

Joel Gallun 
oao corp 

7500 greenway ctr 
greenbelt, md 20770 
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Note 597.2 Having your VAX call you back 2 of 3 

"Bob Hassinger" 7 lines 7*MAR*1987 16:51 

*< Check VAXNET on the SIG tapes >* 

Look at the recent versions of VAXNET on the VAX Symposium Tapes 
(SIG tapes) . I have not actually gotten it to work fully yet 
for callback because of many problems with modems, lines, etc. 
but all indications are that it has the right answers. Even if 
you do not use the code the method should be helpful to study. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617*435~9061 


Note 597.3 Having your VAX call you back 3 of 3 

"Joel Gallun" 16 lines 10&MAR*1987 17:28 

call back program source code > a 

I have left the source code for the call back program I 
mentioned in the other reply in my login directory. The files 
are: call_back.for call.for subs.for call_back.com 

It is set up to work with our Rolm digital PBX and may not be of 
any use to you. The authors phone numbers are in the source 
files. The area code here is (301) and our exchange is 286. I 
belive that only the last 5 digits of their phone numbers are 
there. 

In regard to the other reply, VAXNET has been a very useful 
program to me, also, and I wouldn't be at all surprised if the 
latest and greatest version could do what you need. 

Joel Gallun 
oao corp 

7500 greenway ctr 
greenbelt, md 20770 
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Note 598.0 DNA DAP manual order # needed 4 replies 

"Jamie Hanrahan" 10 lines 26**FEB* i 1987 17:17 

Does anyone have the order number for the Digital Network 
Architecture Data Access Protocol Functional Spec.? 

(It sure would be nice if the Electronic Store let you look up 
manuals by title substrings... all of the DNA Func Specs that I 
have order numbers for are in the store, at least I was able to 
do price lookups on 'em.... but when I did a product lookup by 
keyword, using keywords that should have found them, none of 
them appeared.... I guess manuals aren't "products".) 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*4565*^1865 


Note 598.1 DNA DAP manual order # needed 1 of 4 

"Larry Kilgallen" 5 lines 27*FEB*1987 13:11 

*< AA*K177A*TK >* 

DNA Data Access Protocol (DAP) Functional Specification, Version 

5.6.0. 

It would also be nice if the Electronic Store had sent me this 
document when I ordered it, many moons ago. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*40901 


VAX-59 








PAGESWAPPER « May 1987 * Volume 8 Number 10 
INPUT/OUTPUT 


Note 598.3 DNA DAP manual order # needed 3 of 4 

"Jan C Ostendarp" 5 lines 16*MAR*1987 19:19 

*< Software Products Doc. Dir. >* 

DEC publishes a quarterly? Software Documentation Products 
Directory. Stay tuned for the contact name (address) to get on 
the mailing list. 

Jan 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 598.4 DNA DAP manual order # needed 4 of 4 

"Jamie Hanrahan" 15 lines 16*MAR41987 22:29 

*< Thanks, but I already have that I >* 

I already receive the Software Products Doc. Dir. The Digital 
Network Architecture and Protocol Specifications do not appear 
in it. 

In Dallas I mentioned this lack to one of the people in the 
Documentation booth in the display area. Lo and behold, the 
good folks came up with a little booklet called "Networks and 
Communications Publications (Fall 1986)", available on the 
display floor in San Francisco! It listed *almost* all of the 
DNA A&PS books, *except* for the DAP and DDCMP manuals. (I 
already had that one, though. For others 1 benefit, its number 
is AA a D599A~TC•) 

(Alas, this little booklet doesn’t seem to have a number, so you 
can’t order it. Maybe they’ll have them in Nashville.) 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 
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Note 599.0 Any PSI users out there? 5 replies 

"Jamie Hanrahan" 4 lines 28*FEB*1987 00:51 

Is anyone who reads this using VAX PSI? If so, what for? Are 
you using it for task^to*task links, for PSI Mail, X.29 virtual 
terminal support, DECnet data links, what? What have your 
experiences been? 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 


Note 599.1 Any PSI users out there? 1 of 5 

"Larry Kilgallen" 14 lines 28*FEB*1987 11:17 

*< One trying to be a former PSI user >* 

I have a client site which chose PSI for DECnet data links in 
order to save the cost of renting a full*time circuit to a 
far*away country. Thus their use is essentially that of a 
point-to*point link. They have since given up on PSI and are in 
the process or ordering a full*time circuit due to the excessive 
staff time required to keep PSI software going on both ends of 
the link (staff costs and packet costs together exceeded the 
cost of a full-time circuit). 

My summary of this experience would be that there was no need 
for the design benefit of packet*switch technology (multipoint, 
etc.) in this situation, and simply using it as a replacement 
for full*time circuits was not cost effective. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 
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Note 599.2 Any PSI users out there? 2 of 5 

"Mark Oakley" 8 lines 3*MAR*1987 16:19 

*< More PSI Info Requested >* 


We are working to provide DECnet service to one of our labs in 
Europe via PSI. Larry's reply about problems with PSI is very 
important to us, and we would like more information. Can anyone 
elaborate on the problems? Is there anyone who can provide us 
with someone to talk to? I can be reached at (614) 424*7154 and 
would welcome a call. We plan to implement this DECnet service 
soon, so whatever information could be provided would be much 
appreciated. 

Mark Oakley 

Battelle Memorial Institute 
505 King Ave. 

Columbus, Ohio 43201-2693 
614/424*7154 


Note 599.3 Any PSI users out there? 3 of 5 

"Jamie Hanrahan" 2 lines 3* i MAR*1987 19:43 

*< source for PSI. >* 


Larry (or anyone else who knows), does PSI V2.n still come with 
source fiche? 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 
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Note 599.4 Any PSI users out there? 4 of 5 

"Larry Kilgallen" 10 lines 3*MAR*1987 22:28 

m< No source today, the fiche have gone away >*» 


It is my understanding that source fiche are NOT available at 
any cost to non^DEC personnel (not even BI bus driver writers) • 
They may be available to DEC software specialists. The reason 
given was that DEC has invested a great deal of time and effort 
in understanding how 20 different PSDN vendors have separately 
interpreted the X.25 and X.29 specifications, and DEC views the 
fruit of that interpretive effort as highly proprietary giving 
them a competitive edge. Sort of like someone who reverse 
engineers the BI bus not wanting to share it with the world... 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 


Note 599.5 Any PSI users out there? 5 of 5 

"Mark Oakley" 3 lines 10-MAR*1987 16:36 

*< Still Interested in PSI Info >*- 

I am still very much interested in anyone's (negative) 
experiences with PSI. Larry's reply (599.1) suggests that it is 
a poor approach for trying to DECnet sites that are oversees. 

Mark Oakley 

Battelle Memorial Institute 
505 King Ave. 

Columbus, Ohio 43201*2693 
614/424*7154 
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Note 600.0 UIS Libraries for Modula-2 No replies 

"Offline Submission" 11 lines 2*MAR*1987 20:43 


Has anyone developed or know where to find UIS libraries for the 
Hamburg Modula-2 compiler? I would like to use Modula-2 on a 
VAXstation II/GPX. 

Keith Berhard 
10608 North East 4th 
Bellevue, WA 98009 
Telephone: (206) 462*3106 

February 23, 1987 


Note 601.0 high-speed dialup modems? 5 replies 

"Jamie Hanrahan" 15 lines 3MMAR^1987 15:52 


It seems to me that I've seen some ads for modems that run at 
9600 bps, full-duplex, (and also 300/1200, Bell 103/212 
compatible) over the dial-up network. If I remember right, they 
hook up to async DTEs, but may actually run in sync mode at 9600 
(transparently to the async DTE) , and they can be autodialed via 
commands to the serial port. 

Does anyone have any hard information on these? Better yet, 
does anyone have any experience with them? 

"You are trapped in a maze of twisty UUCP connections, all 
different." 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565-1865 


Note 601.1 high-speed dialup modems? 1 of 5 

"Jack Patteeuw" 12 lines 5-MAR41987 18:02 

-< Check Codex >- 


Although I have no personal experience with them, I see that 
Codex (a very reputable communication company) has two modems 
similar to what you are describing. 

The 2206 does half^dup sync at 9600 bps (V.29 compliant) and the 
2260 does full-dup sync at 9600 bps both over over normal 
dial-up lines. These units do NOT support async or 300/1200 
bps. 

I have purchased other equipment from them in the past and rate 
them excellent 1 Codex can be reached at 1-800-446-6336. Ask 
for a copy of their Direct Order Catalog. It has lots of good 
info even for the neophyte and include prices on their most 
popular equipment. 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313-323-8643 


Note 601.2 high-speed dialup modems? 2 of 5 

"Bruce Bowler" 7 lines 9-MAR-1987 13:28 

-< Try VADIC also >* 


We have had a pair of Racal-Vadic 9600 VP modems for about 6 
months now that have worked quite well even on some really poor 
phone lines. They are noticeably faster at painting a screen, 
but you can tell that they are stuffing stuff into packets on 
each keystroke (this, as the main note pointed out is 
"transparent" to the user, i.e. no code changes required). 
These modems will autodial, at least from the keyboard, and we 
use them in a VT240<--->DMF32 hookup. 

Bruce Bowler 
General Electric 
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1 River Road 
Bldg 2 Room 609 
Schenectady, NY 12345 


Note 601.3 high-speed dialup modems? 3 of 5 

"Jan C Ostendarp" 14 lines 16-MAR-1987 19:42 

-< Try TELEBYTE (Accelerators) >- 

I have been using a pair of Telebyte Corp's Accelerator series 
24* s (as in 2400bps) which work very well together and with 
other modem equipment (V.22bis, Bell212A, Bell2400) . They 
"fall-back" to the appropriate mode as the remote modem 
requires. 

AT command set, memory (symbol table), security codes, call-back 
options, multiple configurations stored in memory, etc. 

If I may refer you to then people who can tell you more about 
them, call me: 

Jan Ostendarp 617-423-3500 x2207 
Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 601.5 high-speed dialup modems? 5 of 5 

"David Shepperd" 17 lines 25-MAR-1987 19:34 

-< It actually runs at 19,200 too 

We did a little research into these and picked the IRMA 
FASTLINK. It uses the Hayes AT command set and worked perfectly 
with our programs that speak Hayeseeze. As long as you keep 
your typing ahead to a minimum, it's just as though you* re 
connected locally at 9600 baud. Although we didn't expect it, 
they also will connect to and speak at 2400 baud to one of those 
2400 baud modems. 
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I strongly recommend that you get a demo unit and try running 
EDT or TPU on any of these 9600 baud gizmos before you buy one 
lest you be VERY disappointed. 

D. Shepperd Atari Games (408) 434-1711 

David Shepperd 
Atari Games Inc 
675 Sycamore 
PO BOX 361110 
Milpitas, Ca 95035-1110 
(408) 434-1711 


Note 602.0 LK201 Hardware info 1 reply 

"Jack Patteeuw" 10 lines 5*MAR*1987 17:39 

We (Ford Motor Company) are building some custom hardware and 
would like to use the LK201 keyboard as an input device. 

Does anyone know (or know how to get the documentation for) the 
signals on the four wire going to/from the keyboard (I assume 
they are power +?V, ground, transmit and receive) and what code 
the keyboard send to the terminal (is it ASCII with start and 
stop bit similar to RS232 or what). 

Any information would be greatly appreciated. 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313-323*8643 
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Note 602.1 LK201 Hardware info 1 of 1 

"Jamie Hanrahan" 17 lines 6-MAR*1987 18: 56 

%< this may help... >* 

We have a copy of the Professional 300 Series Technical Manual. 
Its order number is EK*PC350*TM^001. It does not give 
electronic interface information for the keyboard (other than 
that the line driver for keyboard output needs *10V, which is 
generated internally from the +12V that's supplied), but it does 
provide complete information on the data codes. It is serial 
transmission, eight data bits plus a "0" start bit and a "1" 
stop bit. The data sent by the keyboard is nothing like ascii, 
however. For instance, pressing the shift key generates a 
keycode; it does not modify the keycode sent by the "A" key. 
Looks like a whale of a lot of fun (?) to use, but all the info 
you'd need seems to be here. 

It shouldn't be all that hard to figure out which of the four 
wires are which, or what the electrical interface is, either by 
attaching a scope or by opening the enclosure and looking at the 
types of driver/receiver chips that are used (or both) . 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 


Note 603.0 Using TK50 for BACKUP 8 replies 

"LARRY CHIANO" 9 lines 10PMAR*1987 16:05 

We are designing a Local Area Vax Cluster, initially consisting 
of 1 MicroVax II, 1 MicroVax 2000 and 2 disk drives totalling 
about 750Mb of storage. We are trying to decide between a TK50 
and 9 Track tape for the system's only tape drive. 

Any opinions or comments on the TK50 would be welcome. 

LARRY CHIANO 

LEMESSURIER CONSULTANTS, INC 
1033 MASS AVE 
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CAMBRIDGE, MA 02138 
617^-868*1200 


Note 603.1 Using TK50 for BACKUP 1 of 8 

"Joel Gallun" 12 lines 10*MAR*1987 17:21 

*< Opinions on TK50s >* 

DEC is not currently supporting 9 track tapes as distribution 
media for MicroVMS, which means that you will have to have 
either a TK50 or a RX50 device to load VMS off of. I have 2 
TK50s on MicroVAXes here and haven't had any problems with them. 
Rumor has it that they are rather fragile, mechanically, that 
is. They are awful slow running anything but Backup, i.e. 
Copy. It takes about 45 minutes to backup a rather full RD53 to 
a TK50 using the command "backup/image/buffer=5 dua0: 
mua0:file.bck/save". If you disable crc it goes faster because 
the microVAX does crc in software rater than hardware, and the 
TK50 does a crc in its hardware anyway. I would say that if you 
only need a backup device the TK50 is ok, but if you have other 
uses go for the 9 track. 

Joel Gallun 
oao corp 

7500 greenway ctr 
greenbelt, md 20770 


Note 603.2 Using TK50 for BACKUP 2 of 8 

"Larry Kilgallen" 16 lines 10*MAR*1987 18:16 

*< A TK50 Fan >* 

I have been quite happy using TK50S for backup in typical 
MicroVAX situations ** meaning the machine does not have to be 
up 24 hours. An RD53 may take a long time (I always use 
/VERIFY) but the whole disk fits on one cartridge and one can 
leave the backup running at night and reboot in the morning. 
Even at a site which uses an RD54 for its system disk, I find 
that arriving after a period of absence (during which the first 
TK50 was filled) putting in the second cartridge and waiting for 
it to finish is quite acceptable (the first cartridge having 
taken the brunt of the data). At this site there is also a 
TSV05 9 track tape drive, and its is used mainly to make tapes 
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for distribution to MacroVAX sites. The story might differ if 
the tape drive in question were a TU81E (plus) , but there is 
about a 25/1 price ratio in the cost of that drive to the TK50 
drive. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 


675 Sycamore 
PO BOX 361110 
Milpitas, Ca 95035^1110 
(408) 434*41711 


Note 603.5 Using TK50 for BACKUP 5 of 8 

"Lora Wether ill" 6 lines 26*MAR*1987 17:27 

-< NO MORE TK50 * s! >- 


Note 603.3 Using TK50 for BACKUP 3 of 8 

"MICHAEL GRATTAN" 6 lines 25-MAR-1987 07:47 

-*< More on TK50 >- 


We have used a TK50 for 
with very few problems 
nasty rumors about the 
Digital Review, etc.) 
IBMer. Overall, we are 
toying with the idea of 


backups (both incremental and /IMAGE) 
for about nine months. I have read some 
TK50 and various publications (i.e. 
but I think that they were written by an 
pleased with the drive and have been 
installing a second one on the MicroVAX. 


MICHAEL GRATTAN 
FAIRHAVEN CORP. 

358 BELLEVILLE AVE. 

NEW BEDFORD, MA. 02742 
617-993-9981 EXT 106 


I am responsible for nine MicroVAXes, and, in the past year have 
had TK50's replaced on all but three of them, and lost a dozen 
cartridges. Several systems have had the TK50 replaced multiple 
times. I'll take a TSV05 ANYDAY (and wouldn’t THINK of even 
touching an IBM...I). 

Lora Wetherill 
P.0. Box 179 
Mail Stop 10096 
Denver, Colorado 80201 


Note 603.6 Using TK50 for BACKUP 6 of 8 

"Frank J. Nagy" 22 lines 28-MAR-1987 11:39 

~< TK50 OK, but getting TU81+ anyway >- 


Note 603.4 Using TK50 for BACKUP 4 of 8 

"David Shepperd" 11 lines 25^MAR-1987 19:12 

*< Still more about TK50 >- 


We have 2 MicroVAX II each with a TK50. They have been running 
for over 1 year now without any trouble. Each MicroVAX has, 
however, roughly 600Mb so backups run about 4 hours taking 
between 4 and 6 tapes (each) depending on how full the disk is. 
I do recommend you use /BLOCK=32768 to save tape. We haven't 
had any carts break but did notice that about 1 in 50 fail such 
that tape and/or drive continuously reads (searches?) as though 
it can't find BOT or something. 

David Shepperd 
Atari Games Inc 


1. We have had 4 VAXStation-II/RCs running for several 
months now. Each has an RD53 and a TK50. We have a 
batch job setup to do a full backup very early in the 
morning; the systems manager comes by in the morning 
and changes cartridges. This has worked quite well and 
we have had no problems with cartridges nor the TK50 
drives. 

2. We have also just started using an LAVC of 2 MicroVAXes 
with 2 RA81s. Each MicroVAX has a TK50. Now problems 
as of yet. I understand the best way to do BACKUPS is 
to use a large block size (/BLOCK=32768) and to do 
/NOCRC (requires less CPU time on the MicroVAX and may 
give better overall performance by needing less tape 
repositioning). 
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3. We plan to add 2 more RA81s this summer on the LAVC. 
Since our systems manager has other things to do (other 
than BACKUPS that is) we are also planning to add a 
TU81*Plus to the system. I saw the QBus TU81 + at Fall 
DECUS and was impressed. Although the tape was 

repositioning LOTS, the BACKUP demonstrated was 

dominated by head motion on the RA81. To the MicroVAX, 
the TU81+ seems to run at full speed (75 ips) . Of 
course, one does 6250 bpi backups with large blocks and 
/NOCRC to get best performance. 


Frank J. Nagy 
Fermilab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840*4935 


Note 603.7 Using TK50 for BACKUP 7 of 8 

"Larry Kilgallen" 8 lines 29nMAR*1987 20:20 

-< Backup mileage from your disk may vary >*•* 

Regarding .6: 

It would seem to me that on a properly defragmented disk, head 
motion during an image backup would not dominate. Of course 
using a disk which has not been defragmented recently (according 
to the frequency and nature of new allocations and 
deallocations) can make the tape drive not be at fault. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
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Note 603.8 Using TK50 for BACKUP 8 of 8 

"Jack Patteeuw" 12 lines 30*MAR*1987 17:20 

-< Minor problem >~ 


We have had a MicroVAX II with a RD53 and a TK50 for about a 
year now and have experienced no cartridge failures. Most 
BACKUPS are done over the network so the only real work the TK50 
does is for IMAGE Backups. 

I have had a problem where the MOUNT would give an error message 
that the device was not "software write enabled" or something 
like that. This usually required rebooting the machine to get 
VMS to be able to "talk" to the TK50 again. 

I have been told that this is a firmware error and has been 
fixed. Can anyone confirm this ? 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323-8643 


Note 604.0 VAX 11/750 Boot ROMs No replies 

"Offline Submission" 17 lines 11-MAR^1987 22:15 


The VAX 11/750 Boot ROMs permit the CPU to be booted from the 
indicated device on the master Unibus (UB0). When adding a 
second Unibus, the system device must stay on UB0. I want to 
put my system device on UB1 and be able to boot from there, but 
I need a boot ROM that has the UB1 adapter on it. DEC has said 
they cannot supply that item. Where can I obtain a boot ROM 
with RA81 and RK07 devices on UBl (NEXUS=9)? 

J. Bradley Flippin 

Raytheon Service Company 

2341 Jefferson Davis Hwy (#1200) 

Arlington, VA 22202 
Telephone: (703) 685*2337 
Date: March 9, 1987 
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Note 605,0 Barcode on LN03 Plus 1 reply 

"Offline Submission" 13 lines 11*MAR*1987 22:15 

We want to print barcodes on an LN03 Plus using a VAX750 running 
VMS V4.4. Can anyone help us to find such a program, if 
possible a FORTRAN program? 

Willy Gomm 

INBIFO Institut f. biologische Forschung GmbH 

Fuggerstr. 3 

DM5000 Koln 90 

Federal Republic of Germany 

Telephone: (+ 2203) 303396 

Date: March 5, 1987 


Note 605.1 Barcode on LN03 Plus 1 of 1 

"Jonathan Pinkley" 14 lines 20MMAR*1987 20:06 

4< Using TeX to produce Barcode on LN03 >* 

This is a bit of a hack, but we are currently producing bar 
codes on an LN03 with a font ram cartridge. The software being 
used to do this is LaTeX (the K & S distribution using the 
DVI2LN3 driver.) 

We defined LaTeX commands for each bar code character. This is 
not recommended for high volume work, since the LaTeX program is 
quite CPU intensive. If you are only producing low volume, it 
will work, and the TeX / LaTeX software is available for 
distribution costs. 

A more elegant approach using TeX would be to use MetaFont to 
create a font for the barcode. This would make the production 
of bar codes with TeX very easy. The current approach is to 
produce the character ’T’ bar code with a \BART etc. 

Jonathan Pinkley 
Gould OSD 
Dept. 913, Bid. 2 
18901 Euclid Avenue 
Cleveland, OH 44117 
(216)486*8300 xl335 


Note 607.0 DECserver 200 application ports * how? 4 replies 
"Bob Hassinger" 44 lines 16 a MAR*1987 17:12 

Does anyone have any experience connecting to a DECserver 200 
port from a program on a VAX? We have an 11/750 connected to a 
small Ethernet with a couple of DECserver 200s. A couple of 
modems are connected to ports on one of them and set up per the 
book as "dynamic" * you can call in, talk to the server and 
connect to the VAX fine. The modems are offered as "services" 
that other ports on the server can connect to and dial out 
through, also just fine. 

Since most of our users are still on conventional VAX ports, it 
would be nice if they could also connect to the modems and dial 
out. Before the modems were moved to the server this could be 
done quite nicely using SET HOST/DTE or better yet via the 
VAXNET or KERMIT programs. One might think the DECserver 200 
would be able to what is required since you can indeed set up 
remote print queues from the VAX to server ports and I thought 
it had been implied if not stated that arbitrary programs could 
do the same. (We are going to need to be able to accept input 
from a lab instrument connected to a server port soon for 
example). 

Well: I tried CREATEing a port then SETing it /APPLICATION with 
LATCP as the documentation shows for the remote printer case but 
when I allocate the port and try SET HOST/DTE or VAXNET in the 
usual way I get no response from the modem. Colorado Telephone 
Support broke the news that this is unsupported! They did 
indicate that VMS V4.6 "had support" or maybe just documented 
what to do for a case like a program simply sending output to a 
port like this. I don’t have and don’t know when I will see 
V4.6 however and I need to get the modems going on the server if 
I can. 

Does anyone know anything about this? I am interested both in 
getting a capability going for dialout applications as easily as 
possible and also in how to write programs to interact with 
server ports as we have always been able to do with conventional 
ports. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
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Hopkinton, MA 01748 
617*43549061 


Note 607.1 DECserver 200 application ports * how? 1 of 4 

"Jan C Ostendarp" 15 lines 164MAR41987 20:53 

«< DS200 4 got a waa story? >* 

I share your interest in getting the DECserver 200 to do all the 
things one might expect reverse LAT with modem control to do. 
Specifically a modem pool for incoming and outgoing calls. DEC 
wants us to believe that their Ethernet product set can replace 
and exceed the functionality of data switch products. I'm 
hoping the DECserver 100 and 200 command set lends itself to use 
with PC packages which expect to find a hayes modem on C0M1: 
(of course C0M1 will be an asynchronous connection to DECserver 
200 port) Modem pools work best if the resource is released when 
when the phone connections drops off. Does anyone out there 
have some experiences with DECserver 200's they'd like to share? 

Jan 0 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 607.2 DECserver 200 application ports * how? 2 of 4 

"Bob Hassinger" 16 lines 174MAR41987 09:32 

4< Sharing via ports OK, LAT not so good >* 

I am not clear just how transparent you can make the situation 
you ask about. It may be that you will have to type a command 
to the server to get connected to the desired modem or group of 
modems. It depends on the specifics of everything you want to 
be able to do. In general however it looks like you can do a 
lot of the kind of sharing you are interested in, except for the 
case I asked about. 


If your computer is going into the server via one of the ports 
as with a PC, things are fine. It seems the problem is with 

computers accessing the server via the network 4 that is via the 

LAT protocol * as the VAX normally does. It seems as though 

there are still some problems establishing the logical 

connection in this case. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617*43549061 


Note 607.3 DECserver 200 application ports * how? 3 of 4 

"MICHAEL GRATTAN" 5 lines 25*MAR*1987 07:55 

4< More on Decserver 200/MC >* 

I had set up a modem as you have done using LAT and creating a 
port, etc. I found that we had to use a full modem cable (a la 
BC22E) to get any results. It did work but was a little 
insecure, the service would lock up. I wound up putting the 
modem back on the DZQ. I hope this helps. 

MICHAEL GRATTAN 
FAIRHAVEN CORP. 

358 BELLEVILLE AVE. 

NEW BEDFORD, MA. 02742 
617“993*9981 EXT 106 


Note 607.4 DECserver 200 application ports * how? 4 of 4 

"Bob Hassinger" 15 lines 27*MAR41987 09:05 

*< More info on .3 please... >4 

Re: .3 That is very interesting. One of my modems may have a 

problem with it's cable but the other seems to have enough pins 
supported. It would be helpful to know more about your 
experience such as what software was used to access the port. 
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Also, by "insecure" what do you mean. Just that the modem gets 
hung or that there is a security (i.e. unauthorized access) 
problem? I am seeing some problems here with modems not 
disconnecting after certain types of line problems and attempts 
to "disconnect" from them to hang up and clear the problem. The 
port stays in a "disconnecting" state so you can't use the 
modem. The only way out seems to be to turn on privileges and 
logout the port. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617443549061 


Note 608.0 VMS 4.5A installation 4 LAVC 1 reply 

"Jan C Ostendarp" 20 lines 16“MAR4l987 20:37 


Version VMS 4.5A installation initializes the system diski 

Installing this version on an existing VAX (as in converting a 
VAX-11/780 to the boot node of a Local Area VAXcluster) creates 
a royal headache restoring site-specific files from the 
pre-installation backup... not to mention re-installing layered 
products. Have I convinced you it was a long nightmare of a 

weekend? It was. A command procedure I wrote helped me 

identify files which didn't exist on the new system disk. They 
included user-created symbolic definition files (i.e.VAXC .H in 
sys$library, Device Control Libraries, V3F0RSYSDEF.TLB, 
netnode.dat etc. 

THE QUESTION: Does anyone know DEC'S rationale for releasing 
the distribution with this inconsiderate installation procedure 
instead of as standard VMS upgrade (as in VMS 4.0, 4.4)? 

Colorado doesn't know. Apparently, it isn't related to cluster 
sys disk structure. QUESTION 2: Does anyone want to talk about 
their experiences with the performance or on-going system 

management of a local area VAXcluster? 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 608.1 VMS 4.5A installation 4 LAVC 1 of 1 

"David Shepperd" 21 lines 25-MAR41987 18:54 

-< 4.5A is certainly a pain >- 


Yep. It's a royal pain to install 4.5A on an existing system. 
What I did is rename the SYS0 directory where the existing 
system lived to SYS1 and booted it. Then used online BACKUP to 
restore the REQUIRED saveset from the distribution tape to 
[SYS0...] and booted the new SYS0 which proceeded to complete 
the install as though the disk had been initialised. I had a 
command procedure look through the SYS1 tree and rename files 
from SYS1 to SYS0 if they weren't already there. This was done 
in early January '87. There are a couple of caveats re any 
alias directories that might exist in [000000]. Call me for 
details. 

Re the "way did they do that?", it is apparent that the 4.5A was 
mastered between 4.5 and 4.6. Some things in the installation 
(upgrade) think that it's installing a 4.5 upgrade and some 
things think that it's doing a 4.6 upgrade. Since VMSKITUPG (or 
whatever) looks in a directory named after the upgrade kit and 
version ([.VMS045] for example) for the appropriate files, it 
fails when it can't find anything in [.VMS046] (guess how I know 
this). DEC must have "hurried" this to SDC not wanting to take 
the time to correct it. 

David Shepperd 
Atari Games Inc 
675 Sycamore 
PO BOX 361110 
Milpitas, Ca 95035-1110 
(408) 434-1711 
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Note 609.0 Utility to read/write IBM tapes 3 replies 

"Jack Patteeuw" 3 lines 17*MAR*1987 17:34 


I'm certain that somewhere in one of the DECUS libraries there 
is a utility to read IBM tapes. Can anyone point me in the 
right direction ? 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323*8643 


Note 609.1 Utility to read/write IBM tapes 1 of 3 

"Bob Hassinger" 17 lines 18 i4 MAR»1987 09:57 

*< Get IBM to write ANSI or try MTEXCH >* 

My limited experience indicates there is no such thing as an 
"IBM tape". There seem to be many different formats that come 
out of IBM operations. In our particular case we just get our 

EDP people to have the tape written in a suitable format that is 
fairly easy for VMS to read using standard facilities. 
Depending on the particular system and OS, the IBM side seems to 
have a lot of flexibility in how they write their tapes, 
including ANSI labeled format. 

When this does not work I fall back on MTEXCH. It was on a 
Symposium SIG tape a few years back * attributed to Battelle I 

think. It seemed to be the best for our needs at that time. 

There have been MANY programs in this space over the years on 

the tapes. Because of the wide variety on the IBM side the 
programs tend to differ a lot in what they do. You have to look 
at them carefully to find the best fit with your needs. 

Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617*435*9061 
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Note 609.3 Utility to read/write IBM tapes 3 of 3 

"Frank J. Nagy" 12 lines 22*MAR*1987 11:55 

*< IBM tape utilities on VAX SIG tapes >* 

Don't remember which tapes things are on, but here are some 
program/file names or other directions: 

1. ETAPE (reads tapes blocked/unblocked, especially with 
fixed length records, can handle ASCII and EBCDIC 
tapes). 


<funny name> Look in Glenn Everhart's contributions 
(under RCAxxx usually) for an oldie*but*goodie which 
has been ported from RSX to VMS. 


Frank J. Nagy 
Fermilab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840*4935 


Note 610.0 
"MICHAEL GRATTAN" 


DECnet DOS 3 replies 

13 lines 18*MAR*1987 13:13 


I am trying to connect a PC/AT to my MicroVAX II via DECnet DOS. 
The PC/AT is hardwired to the DZQll. The line and circuit 
states seem ok, but every time I try to connect from either the 
MicroVAX or the PC/AT I get "Node unreachable". Can anyone give 
me any ideas? The documentation for the MicroVAX is minimal at 
best. Thanks. 


MICHAEL GRATTAN 
FAIRHAVEN CORP. 

358 BELLEVILLE AVE. 

NEW BEDFORD, MA. 02742 
617*993*9981 EXT 106 
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Note 610.1 DECnet DOS 1 of 3 

"Jack Patteeuw" 2 lines 19*MAR*1987 07:32 

*< Area Problem ? >* 

One quick suggestion, make certain that both nodes are in the 
same DECNET area ! If not, they won't synch up. 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323*8643 


Note 610.2 DECnet DOS 2 of 3 

"Frank J. Nagy" 25 lines 22-MAR*1987 11:52 

M< Hints on Async DECnet^DOS >- 

First, you gotta look in the DECnet documentation which comes in 
the complete VMS documentation set (yes, I know that the 
complete VMS set price may represent 10% of the cost of the 
MicroVAX, but the MicroVMS documentation set is pretty much 
useless if it ALL that you have). 

We had set up a similar configuration (PC*AT to 785 via a 
terminal port on an Able VMZ/32) quite a while back (>1 year?) . 
Now we have 1 (and soon to be 5 more) PC*ATs connected via 
Ethernet using DECnet*DOS and Micom/Interlan Enet boards. 

As I remember, to get things to work properly, you must install 
the VT driver (virtual terminal) on VMS and set the DECnet line 
as DISCONNECTable. We actually had async DECnet working between 
the VAX and PC first using a dedicated line and then changing 
over to dynamic switching. To do the dynamic switching, the 
line is setup as a normal interactive terminal line. On the PC 
we would use Kermit to log into the VAX and then do something 
like SET TERMINAL /DYNAMIC/SWITCH [WARNING: don't take this as 
gospel, my manual set is not beside me and my memory i vague 
here]. A control*]C would get us back to the Kermit^MS prompt 
on the PC. We would exit Kermit and use NCP (on the PC) to 
start DECnet (SET LINE C0M*1 STATE ON) . Worked like a charm. 
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Frank J. Nagy 
Fermilab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840*4935 


Note 610.3 DECnet DOS 3 of 3 

"MICHAEL GRATTAN" 8 lines 25^MAR*1987 08:02 

*< Problem SolvedI >* 

a & ± a & A & * n * * * u * a & ± ** u a & u u * u * u a & * & a * *&*****■*>*& 

I want to say thanks for all the help, it is greatly 

appreciated. I should have given more detail. The MicroVAX is 
an end*node as opposed to a routing*node and we are running 
Decnet with terminal servers. As the MicroVAX is an end node it 
can only recognize one circuit 'on' at a time. Dec instructed 
us to turn the circuit to the terminal servers off as it was 
only used during initialization. This worked like a charm and 
the whole thing has been working quite well. Thanks. 

MICHAEL GRATTAN 
FAIRHAVEN CORP. 

358 BELLEVILLE AVE. 

NEW BEDFORD, MA. 02742 
617*993*9981 EXT 106 


Note 611.0 LAVC Performance 14 replies 

"Jan C Ostendarp" 32 lines 18*MAR*1987 15:04 

LAVC * Performance Issues 

It is hard to get an answer from Colorado about what acceptable 
performance is in an LAVC environment. Does anyone out there 
have experience running LAVC with a VAX*ll/780 (ample*memory) as 
a boot node and 1 MicroVAX II in the cluster? Let's talk. My 
concern is that my network may be degrading performance of my 
MicroVAX cluster member. 
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We purchased a VAX II to run in LAVC environment with an 
existing VAX^ll/780 which was used for application development 
(3 programmers^ language editing, compiling, linking) and 
end-users. Memory is ample on both machines«16MB (70% used / 
30% used.) The 11/780 has 2 RA*81 disks-*system and user. CPU 
used is distributed well over the two machines when the 
developers are using the VAX II. The VAX II has a local RD53 
for paging and swapping. 

The performance problem seems to be doing things from the 
MicroVAX which access (and read) a lot of files on the served 
user disk, for example LINKING (which programmers tend to do a 
lot.) My benchmark on "standalone" system says that while links 
are using the same amount of CPU time on the MicroVAX II is 4 
times that of the same link on a "standalone" 780. (cluster 
common UAF.) We are already doing things like linking to the C 
shareable RTL in order to eliminate the copying of C*RTL objects 
into the image. The two machines a connected via DELNI... one 
other vax (an 750) and 5 decserver’s share the ethernet. If I 
had to guess, the net is not the problem. Any suggestions? 

Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 611.1 LAVC Performance 1 of 14 

"Jan C Ostendarp" 10 lines 18*MAR*1987 15:19 

errata: 611.0 >* 

The benchmark describes in the above note has typos. 

A link was run on each machine (780, MicroVAX II), same link, 
same User, etc. The link was run on each machine with nothing 
else going on on either the machines in the cluster nor on other 
machines on the ethernet. The cpu time was the same on both 
machines, the elapsed time on the MicroVAX II was 4 times the 
elapsed time of the link on the 780. 
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Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 611.2 LAVC Performance 2 of 14 

"George Walrod" 20 lines 19*MAR*1987 09:13 

-< Sounds like a Tuning Problem >3 

Need some questions answered. 

What is the average time that you are spend is the different 
modes (Kernel, Exec, Supervisor, User) ? 

Are you spending any time in different types of wait states 
(Pagefault Wait ....)? 

What are your disk hit rates like? 

Are you pagefault rates like and what type of pagefault are they 
(hard/soft, demand zero, ....). 

What are your lock rates like? 

How fragmented are the disk? 

I have found on LAVC, that tuning is a must. An what you have 
described sound like it might be a tuning problem. These are 
not all the question but a good start. 

George Walrod 
4260*»b chain bridge rd 
fairfax, va 22030 
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Note 611,3 LAVC Performance 3 of 14 Note 611.7 LAVC Performance 7 of 14 

"Frank J. Nagy" 21 lines 22-MAR*1987 11:44 "Jan C Ostendarp" 18 lines 23*MAR*1987 10:32 

-< Dual MicroVAX LAVC Startup >- SHAREABLE LIBRARIES the ANSWER! >•* 


We are just starting (read tomorrow) to switch our development 
efforts to a LAVC similar to Jan's: to MicroVAX*II CPU's, both 
with 16 MB of memory, boot member has KDA50 with 2 RA81's (one 
for system and one for users) , 2nd machine has RD53 currently 
used only for local paging and swapping (about 40% of disk 
devoted to this right now) . Each MicroVAX also has a TK50; we 
are planning to add a TU81^Plus sort of immediately and to add 
another pair of RA81s this summer (possibly with a second KDA50 
to split the disks across the two systems). 

As we gather more experience. I'll try to pass it on. So far, 
just using the systems to get the startup files, etc. in place 
and tested, we have not noticed any major performance problems. 
One thing we have done is to tune the systems to use all that 
memory; this means large WSMAX, large working set quotas and 
very large WSExtents. We have also increased many of the file 
system caching quotas (again, trying to burn memory for 
performance). 

Neither system has terminal lines; all terminals come in via LAT 
or SET HOST so we are hoping to get fairly good utilization of 
both CPUs. 

Frank J. Nagy 
Fermilab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840*4935 


My suggestion to reduce I/O and processing during links by 
creating shareable libraries out of the numerous (7) and large 
object libraries used in our application development has 
"SOLVED" the "performance" problem in our LAVC. 

Approx. 10 hours of work by a programmer converting 7 large 
object libraries to shareable images with the help of an article 
in the most recent DECUS proceedings (and the VMS doc. set) has 
reduced CPU time during links by a factor of 4, and elapsed time 
by a factor of 7. The performance gain is recognized on both 
the 11*780 boot node and the micro*vax II member node. 

Let's talk about turning libraries into shareable images. (see 
EXPERIENCE w/ SHAREABLE IMAGES) note. Thanks to all those who 
assisted on this LAVC performance question. 

Jan 0. pre*shareable library elapsed time on links 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 611.10 LAVC Performance 10 of 14 

"Jan C Ostendarp" 12 lines 24^MAR*1987 03:05 

RE: 611.3#Tuning LAVC member nodes ><■* 


re: 611.3 

Frank, can you tell me more about the tuning you did to improve 
file caching? The micro*vax II we're using as development 
machine RARELY uses more the 40% of its 16MB memory with the 
three developers. (WSdef:512, WSquota:1024, WSextent:2048 is 
ample). The developers keep multiple subprocesses around for 
the editor, to run MMS, get mail, etc and still more than 9MB 
around for the free page list. 
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Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 611.12 LAVC Performance 12 of 14 

"John Saunders" 19 lines 25-MAR-1987 21:57 

«< Two Cents Worth >- 


re: 611.10: 

Our site has a MicroVAX II with 10Mb memory, and we also had 
memory utilisation problems. One thing we tried was to increase 
the size of the modified page list: if this list is large 
enough, VMS won't feel obligated to write processor ivate 
modified pages to the page file on the (slow) system disk. 

This has also allowed us to decrease the size of our page file 
on the system disk, since this type of page will not be written 
to disk as often. This also removed an occasional VMS hang we'd 
experience, when someone would try using EVE on a huge file 
(5000 blocks or so) . Colorado Springs says that the hang occurs 
when VMS can't write the first page in the modified list to 
disk, so increasing the modified list size helps by reducing the 
amount in the page file. 

The appropriate SYSGEN parameters are MPW__HILIMIT and 
MPW_LOLIMIT. I modified them in MODPARAMS.DAT by adding the 
same amount to each. 

John Saunders 
FEL Computing 
PO Box 72 

Williamsville, VT, 05362 
(802) 348-7171 


Note 611.14 
"Frank J. Nagy" 
-< RE: 611. 


LAVC Performance 

38 lines 


14 of 14 
28*MAR£1987 11:29 


Jan, we've had about a maximum of 6 users/node on our 
have 

yet to see more than about 30% of the user memory 
course, we have tuned things so VMS uses about 2 MB 
16 MB. The XQP cache tuning was based roughly on a 
8^10 average users with about 3 directories in 
"each", etc. The SYSGEN parameters as listed 
MODPARAMS.DAT are 


|e >~ 

LAVC 

and 

used. 

Of 

out of 

the 

guess 

of 

active 

use 

in 

our 


ACP_SYSACC=40 

ACP_QUOCACHE=50 

ACP_DINDXCACHE=50 

ACP_DIRCACHE=100 

ACP_HDRCACHE=100 

ACP_FIDCACHE=100 

ACP_MAPCACHE= 30 

These were basically set by set-of-the-^pants and may be adjusted 
after we gain more experience running. 

I like the suggestion I just read here about the modified page 
list. Will have to try that one. 


So far, so good. The LAVC seems solid and stable. It certainly 
installed smoothly except for our own indecisiveness with the 
satellite. The first try, the satellite didn't see its RD53 and 
so put all the page/swap file space on the common system disk. 
After the hardware problem was fixed, we reinstalled the 
satellite (SATELLITE_CONFIG REMOVE then ADD) and had all the 
page/swap file put on the RD53. Second thoughts lead to another 
REMOVE*ADD cycle and we now have modest page/swap files on the 
common system disk (RA81) and larger ones (about 3^4 times) on 
the local RD53 which are installed in SYSTARTUP as secondary 
page/swap files. Why? If the RD53 fails or needs a reinit, I 
can still setup to run the satellite node by either using just 
the modest page/swap files on the common system disk or (if 
necessary) increasing the size of same and running without the 
RD53. Somehow that feels safer for now. 
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Frank J. Nagy 
Ferrailab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840^4935 


Note 613.0 ACL Problems 7 replies 

"Jack Patteeuw" 17 lines 19* i MAR«1987 16: 12 

I have noticed two case where the DEFAULT PROTECTION ACE of a 
directory's ACL does not work. 

First, is the case of NOTES ! I have added the ACE 

DEFAULT_PROTECTION,SYSTEM:,OWNER:,GROUP:,WORLD:RW 

to NOTE$LIBRARY directory file's ACL. But, lo and behold, new 
conferences that I create have MY default file protection on 
them. 

Second, if a remote user is accessing a directory via a proxy 
login the DEFAULT_PROTECTION again does not seem to work. 

By the way, it seems a little "dangerous" to have to have NOTES 
conference files set to W:RW. This means that malicious users 
could write a program to go in and fiddle around with the data 1 
Or am I missing something somewhere ? 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313232328643 
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Note 613.1 ACL Problems 1 of 7 

"C J "Buck" Trayser" 24 lines 23^MAR*1987 00:18 

*< Notes has a mind of its own >* 

Hello Jack. 

Seems you have come upon one of the favorite questions for ’New 
Noters’. Because the Notes image is NOT normally installed with 
privileges then the user needs one of two things: 1) W:RW to be 
able to write to a conference, or 2) a ’server' that will write 
for them. 

First, the W:RW is a hold over from previous (internal only) 
versions of Notes in DEC. Future development of Notes will 
encourage the use of the server. Using the server will 
eliminate the need to have W:RW. 

The file protection is a logical OR (.OR.) of your default 
protection plus (S:RWE,0:RWE,:RWE,G:RWE,W:RWE) for Note files 
and your default protection plus (S:RW,0:RW,G,W) for your 
Notebook. 

The best way to get the 'proper file protection' on a conference 
is to create it in your own directory and then use the command 
file MOVE_CONFERENCE.COM in SYS$MANAGER: provided by Notes. 

$ 

C J Trayser 

360 Interstate North Parkway 
Suite 600 2 MS: 6/B4 
Atlanta, Georgia 30339 
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Note 613.2 ACL Problems 2 of 7 

"Jack Patteeuw" 12 lines 23*MAR*1987 09:04 

*< Yes, but ... >* 

If the NOTES program is not installed with privileges (I use the 
standard startup command files) how can NOTES (or any other 
non*privileged program) create files in a directory with a UIC 
based file protection other that the one specified by the 
DEFAULT__PROTECTION ACE ? Is this a ACL bug or a "feature"? 

One proposal that was put in the SIR was to allow a image to be 
installed with a identifier. The corresponding data file(s) 
would be protected with ACL only permitting access via that 
identifier ! That guarantees on access to the file via the 
proper image and no special "server" program is required I! 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323*8643 


Note 613.3 ACL Problems 3 of 7 

"C J "Buck" Trayser" 18 lines 23*MAR*1987 13:47 

*< Notes SPECIFIES its protection mask >* 

I guess I am missing something. Let me see if I got this 
straight. When Notes was installed it created the directory 
NOTES$LIBRARY with the ’appropriate* protection. Since then you 
have placed a DEFAULT_PROTECTION ACE on it which, among other 
things, is to prevent non^privileged users from creating 
conferences. Does this work? Can non^privileged users create 
files in this directory? Is the problem that you are using a 
privileged account and that Notes is setting a protection scheme 
of (Your Default Protection Mask ORed with its internal 
protection mask)? If so, this is the intended behavior, as 
Notes specifically sets the protection scheme, purposefully 
overriding the default (which is only a *default*, not a 
♦mandatory* scheme). 
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If this isn’t the case how about posting a DIR/SECURITY of the 
NOTES$LIBRARY.DIR file here. 

$ 

C J Trayser 

360 Interstate North Parkway 
Suite 600 * MS: 6/B4 
Atlanta, Georgia 30339 


Note 613.4 ACL Problems 4 of 7 

"Jamie Hanrahan" 14 lines 23*MAR*1987 17:40 

*< I want install*withsidents tool >* 

Being being able to INSTALL an image (or, perhaps someday, a 
command procedure) with one or more identifiers is a great idea. 
It is closely related to, but more versatile than, the Unix(TM) 
"setuid" feature. (A Unix user who runs a program or CLI script 
that has the setuid bit set acquires the user identification, or 
uid, of the owner of the program or CLI script for as long as it 
runs.) I understand that Bell Labs has, or had, a patent on this 
aspect of Unix. DEC may be unwilling to add the "install with 
identifiers" feature either because they’d have to pay royalties 
or because of the Not Invented Here syndrome. 

Personally, I think they should add it even if they do have to 
pay royalties. It’d sure make life simpler. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565-1865 
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Note 613.5 ACL Problems 5 of 7 

"Larry Kilgallen" 16 lines 23*MAR*1987 22:57 

*< No, not the dreaded SETUID! >* 


r,e * ; 4: VMS developers have acknowledged the need for 
capabilities in this area for some time. Their code phrase for 
it has been "protected subsystem" for several years now. The 
use patterns of VMS sites seem to be such that the best feature 
would be a mechanism for file protections which granted access 
to that file to a particular class of users ONLY VIA A SPECIFIED 
PROGRAM. No, Jamie, I don't think we want the user to assume 
the UIC of the owner of a program. Then all implementers of 
such programs would have to defend against those who would 
DEFINE/USER sys$output to some file they wanted to trash or at 
least mask with a new version! 


Another key to successful design in this area seems to be that 
it must allow users to grant access without involving the system 
manager. 


Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 


Note 613.6 
"Jamie Hanrahan" 


ACL Problems 6 of 7 

2 lines 24*MAR*1987 21:55 
*< no, not setuid >* 


No, no ** I don't want setuid! I just mentioned it for 
comparison. 


Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 
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Note 613.7 ACL Problems 7 of 7 

"Jack Patteeuw" 11 lines 30*MAR*1987 17:47 

*< I see the light ! >* 


re: .3 

Thanks for explaining it Buck ! 

Being an old DEC*20 person (yes, another one of those) I thought 
that the DEFAULT_PROTECTION meant the MANDATORY file protection 
to be placed on new file (at least that's the way I recall it 
work on 20's). 

I guess there is no way to FORCE a specific file protection on 
all files created in directory, is there ? 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313*323*8643 


Note 614.0 EXPERIENCE w/ SHAREABLE IMAGES 10 replies 

"Jan C Ostendarp" 30 lines 23*MAR*1987 11:35 

The application programmers here are excellent C programmers but 
novices with VMS LINKer, creating and using shareable libraries. 
Hopefully, experienced programmers in the vms environment can 
make suggestions about the use of shareable images, and 
shareable libraries. 

Some questions: 

1. We sometimes get the VMS SECTBLFUL "section table 
(process/global) is full" at runtime with an image 
linked to about eight shareable libraries, and 
sometimes we do not. Is this a matter of altering a 
SYSGEN parameter or something else, like putting all 
the shareable images into one library? 
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2. The manuals suggest that we allow extra room in our 
transfer vector module for routines to be added. 
Wouldn't the required recompile/relink take care of 
this anyway, or are they expecting us to use PATCH? 

3. We tend to get Opcode^reserved*to4Digital errors in 
programs linked with shareable libraries. The debugger 
dies on them and is no help. Does this happen to 
anyone else? 

4. Global variables in C default to shareable/writeable, 
which is not what we generally want. Any alternatives 
to putting the (VAXC specific) readonly and/or noshare 
qualifiers in declarations? 


Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 614.1 EXPERIENCE w/ SHAREABLE IMAGES 1 of 10 

"M. Erik Husby" 25 lines 23*MAR»1987 12:42 

a < Shared Image comments >4 

— — — ___ 

I have had some experience with shared images. 

Section Table full *4 most likely SYSGEN parameters. One must 
have contiguous global page table entries to map a section. The 
system's global page table can become fragmented just as a disk 
can; therefore you may need to make the table large enough to 
hold the maximum number of simultaneous users. 

Extra space in transfer vector *4 have not had to do that. 

Opcode reserved to Digital 4*4 have had that occur when there was 
a mismatch between the shared image's transfer vector and the 
caller's expectations. Specifically, once relinked a shared 
image with an old copy of the transfer vector which did not 
include a new entry point. When an image tried calling the new 
entry point we got the opcode fault. 
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Globals one can use the LINKER'S PSECT command to assign new 
attributes 44 no need to change the source code. 

Hope these comments help. 

M. Erik Husby 

Project Software & Development 
14 Story St. 

Cambridge, MA. 02138 
(617)466141666 


Note 614.2 EXPERIENCE w/ SHAREABLE IMAGES 2 of 10 

"C J "Buck” Trayser" 5 lines 234MAR*1987 14:00 

*< Upping PROCSECTCNT sometimes helps >4 

You might also want to check PROCSECTCNT. The default of 32 is 
normally adequate, but bumping it to 40 may be a quick way to 
'fix' your problem. 

$ 

C J Trayser 

360 Interstate North Parkway 
Suite 600 4 MS: 6/B4 
Atlanta, Georgia 30339 


Note 614.3 EXPERIENCE w/ SHAREABLE IMAGES 3 of 10 

"John Saunders" 11 lines 244MAR41987 00:05 

4< Too many PSECTS >* 

Reply to .1: 

The problem with using the PSECT option is that you need to 
apply it to each and every psect (C "extern" variable) that you 
don't want shared. This can amount to a very large, and 
constantly changing number of PSECT options. 
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The C compiler should really give you a 
"/DONT_MAKE__EXTERNS__SHAREABLE" switch. Does anyone have any 
idea of what the C developers were thinking of when they 
implemented this "feature"? 

John Saunders 
FEL Computing 
PO Box 72 

Williamsville, VT, 05362 
(802) 348*7171 


Note 614.4 EXPERIENCE w/ SHAREABLE IMAGES 4 of 10 

"Jamie Hanrahan" 32 lines 24*MAR*1987 22:11 

*< Fortran does it too >* 

> Does anyone have any idea of what the C developers were 

> thinking of when they implemented this "feature"? 

A C extern variable is implemented just like a Fortran common 
block ** it becomes an OVR, GBL, SHR .psect, so that the linker 
can assign it to the same virtual address space as like*named 
.psects from other object modules. In retrospect it does seem 
like an unfortunate decision ** I’d rather that NOSHR be the 
default (in both Fortran and C) . About the only time you want 
them shareable is when you're building a shareable writable 
section, which you usually want all by itself in an image file 
anyway. 

But we’re stuck with it. One way to avoid the proliferation of 
.psects in C is to treat them more like commons group your 
extern variables into a few extern structs. Then you'll have 
one .psect per struct instead of one per variable, and your 
linker option files won't change so often. 

Back to the LAVC performance issue ** if the shareable images 
live on the big machine, keep in mind that you are improving 
your link performance at the expense of runMtime performance, 
since page faults to the shareable images will have to be 
resolved by going to the big machine's disks (via Ethernet). 
Presumably this will be slower than talking to a local disk on 
your MicroVAX. (Then again, if the MicroVAX's disk is an RD5n, 
maybe not!) 
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If you decide to use the shareable version of the VAX*11 C 
Run*Time Library as well as your own shareable images, read note 
578 ("Reserved identifiers in VAX C", if I recall correctly). 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*565*1865 


Note 614.5 EXPERIENCE w/ SHAREABLE IMAGES 5 of 10 

"Larry Kilgallen" 2 lines 24*MAR*1987 22:24 

*< Disk vs Ethernet speed in LAVC >* 

Note that on the VAXstar, Ethernet access is DMA while disk 
access is not. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 


Note 614.6 EXPERIENCE w/ SHAREABLE IMAGES 6 of 10 

"Edgar Zamora" 6 lines 25*MAR*1987 16:22 

*< extra room in transfer vector module >* 

You should leave room at the end of your transfer vector module 
so you can update your shareable image (i.e. add new routines, 
etc.) without needing to relink existing application programs 
already linked to your shareable image. 

Edgar Zamora 

Manufacturers Hanover Trust Co. 

270 Park Ave., 

New York, NY 10017 
(212) 286*5279 
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Note 614.7 EXPERIENCE w/ SHAREABLE IMAGES 7 of 10 

"Jamie Hanrahan" 16 lines 25*MAR*1987 21: 31 

*< nope, no need to pad transfer vectors >* 

If transfer vectors are used properly there should be no need to 
relink executables when routines (and corresponding transfer 
vectors) are added to a shareable image, even if no "padding" 
existed at the end of the transfer vectors in the previous 
version of the shareable. When you link the new shareable 
image, all of the JMPs in the transfer vectors end up pointing 
to the right places for the routines 1 new locations. But this 
is transparent to the executables, which care only about the 
relative locations of the transfer vectors. I don't know why 
the linker manual recommends the padding area. 

At least one DEC publication (one of the handouts for an 
Educational Services course) recommended that transfer vectors 
be quadword a aligned. To this end, I always put my transfer 
vectors in a .psect that has the QUAD attribute, and then 
precede each with a .ALIGN QUAD . 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619^565^1865 


Note 614.8 EXPERIENCE w/ SHAREABLE IMAGES 8 of 10 

"John Saunders" 19 lines 25*MAR a 1987 22:13 

h< Already "common" among Machines 

Reply to .4: 

Unfortunately, our application is already written, and the code 
we want to make shareable is already implemented on several 
other machines, with different C compilers. 


Also, please note that although FORTRAN programs are often 
written from the beginning with COMMON blocks which contain many 
variables, C programs are often written with many individual 
"extern" variables. We face a major rewrite in order to make 
our library routines shareable. Not only would we have to 
rewrite the VMS code, but since these routines are supposed to 
be identical between machines, we would have to use the VMS code 
on the other machines as well. 

It's unfortunate that DEC'S implementation of these two portable 
languages prevents us from taking easy advantage of this 
powerful VMS feature. A compiler switch in each language would 
allow us to continue to use the same code on the VAX as on the 
other machines. 

John Saunders 
FEL Computing 
PO Box 72 

Williamsville, VT, 05362 
(802) 348*7171 


Note 614.9 EXPERIENCE w/ SHAREABLE IMAGES 9 of 10 

"Edgar Zamora" 3 lines 26-MAR a 1987 11:34 

*< more on transfer vector padding... >* 

I also don't see the need for extra space at the end of the 
transfer vector module, as long as the module is updated 
properly. So why does DEC recommend the expansion space? 
Anybody know? 

Edgar Zamora 

Manufacturers Hanover Trust Co. 

270 Park Ave., 

New York, NY 10017 
(212) 286*5279 
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Note 614,10 EXPERIENCE w/ SHAREABLE IMAGES 10 of 10 

"Jan C Ostendarp" 27 lines 27*MAR*1987 17:13 

Shareable images: psects and symbols >-4 

Some further notes on our experience with shareable images and 
VAX C: 

In regards to the SECTABLFUL error (RE: 614.0), we reduced the 
image's number of psects by using (nonportable) VAX C storage 
classes GLOBALDEF, GLOBALREF which place external variables in 
the $CODE or $DATA psect depending on whether the readonly 
modifier is included. Since $CODE and $DATA are NOSHR we no 
longer have the shareable writable default for VAX C extern 
variables. We prefer this approach to bumping*up PROCSECTCNT or 
GBLSECTIONS (Sysgen Parameters) . 

We have learned the difference between UNIVERSAL and GLOBAL 
symbols in the linker. We think this is related to the opcode- 
reserved* to*Digital error mentioned 641.0. In a shareable 
image, we had declared as a global symbol an array of pointers 
to functions which had bogus addresses at run*time. By 
specifying in the linker option file ,, UNIVERSAL=<array_name>" we 
caused the error to go away, we think because the symbol then 
became accessible (had scope) throughout the entire executable 
image, and not just in the shareable image where it lived. 
However, we do not really understand why this was necessary, 
since the array in question was only ever referenced inside the 
shareable image. 

became (we think). addresses 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 615.0 MASS*11 w/XEROX 3700 printer No replies 

"Jan C Ostendarp" 8 lines 24*MAR*1987 01:43 

Anyone out there using MASS*11 wp on the VAX have a printer 
definition description for the XEROX 3700? 

MEC (vendor) has the def. table for a XEROX 2700 but not the 
3700. It's not a bad place to start but I'd like to avoid the 
job altogether. Many Thanks. 

Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 


Note 616.0 Experience w/RDB,RALLY,TEAMDATA? No replies 

"Jan C Ostendarp" 16 lines 24*MAR a 1987 02:45 

VMS layered products such as Rdb, Common Data Dictionary, 
TEAMDATA and RALLY are Digital's offerings for Database 
management, reporting, and ad*hoc query applications. Does 
anyone out there with experience using these products have 
impressions, war stories, or accolades? Specifically, TEAMDATA 
and RALLY. How do these stack*up to other vendor's products? 
(RTI's Ingres; QUEL, SQL, QBF, Report Writer, EQUEL, etc. or 
Oracle;...). I have heard some benchmark information comparing 
VAX/RDB and INGRES query processing performance but I'm more 
interested in general issues. (although performance IS an 
important issue with RDB' s-^generic. What are the strengths and 
weaknesses of these products? 

Anyone used of VAX Xway? 


Jan 0. 

Jan C Ostendarp 

Massachusetts Financial Services 
200 Berkeley Street 
Boston, MA 02116 
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Note 617.0 INSTALL 3 replies 

"MICHAEL GRATTAN" 15 lines 27*MAR*1987 13:50 


Please forgive this novice VMS user, but my MicroVAX does not 
have full documentation and 'they' don’t want to get me any yet. 
(I've tried pleading...) 

I have some sharable libraries and applications which I would 
like to put into memory using INSTALL. Could you please tell 
me: 

A) If I should INSTALL them shared or not and what's the 
difference is? 

B) How do I figure out how much GBLPAGES etc. each file 
is going to use. 


I would greatly appreciate any assistance. 

MICHAEL GRATTAN 
FAIRHAVEN CORP. 

358 BELLEVILLE AVE. 

NEW BEDFORD, MA. 02742 
617*993*9981 EXT 106 


Note 617.1 INSTALL 1 of 3 

"Larry Kilgallen" 24 lines 27*MAR~1987 21:06 

-< One person's advice >** 

Given that you are going to INSTALL the images anyway, the 
decision as to whether to use /SHARED should be based on whether 
multiple users will be accessing them at the same time. (On 
MicroVAXen this answer is not obvious without knowing how you 
use the machine or plan to use the software) . If each program 
will only have a single user at a time, it will not help to use 
/SHARED. 
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If your images should include any Writeable shareable program 
sections, you will have to use the /WRITEABLE qualifier when 
installing them /SHARED in order for them to function properly. 

This presumes, of course, that creation of writeable shareable 

program sections in the images was not just a coding error. 

Even if you had the linker manual, poring over link maps to find 
the global page requirements for a particular image is a painful 
experience. I would suggest instead that you install your 
images one at a time and use the LIST/GLOBAL command in the 
INSTALL utility to find out how many global sections each uses. 

By the way, you do at least have the full MicroVMS doc set, 

don't you (4 short binders)? 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139*0901 


Note 618.0 $set time and ETHERNET 2 replies 

"CHUCK MCMICHAEL" 13 lines 30*MAR-?1987 10:04 


We use a pair of VAX 11/750's connected via DELUAs on the 
ETHERNET. 

Recently one of our staff had to correct one VAX's time of year 
clock by issuing a $SET TIME for one hour in the past. The 2nd 
VAX then logged a DECNET event 4.18 (Line UNA-0 Adjacent node 
listener receive timeout) that lasted until the 1st VAX's toy 
clock progressed past the moment the $SET TIME had been issued. 
Our other line between the machines (DMF*0) was unaffected. 

Apparently the DELUA depends on the toy clock to decide when to 
send the next "here I am" message. For obvious reasons, we 
haven't experimented with setting the clock ahead or turning off 
DECNET before issuing the $SET TIME, but with daylight savings 
time coming up soon, I thought I should mention this to all new 
ETHERNET users. 

CHUCK MCMICHAEL 
PITTSBURGH CORNING CORP 
800 PRESQUE ISLE DR 
PITTSBURGH PA 15239 
412*327*6100 
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Note 618.1 $set time and ETHERNET 1 of 2 

"George Walrod" 7 lines 304MAR*1987 14:05 

4< Another Victim >- 

I've had the same problem with DECnet as a whole, an submitted 
an SPR. Their (DEC) response was that the TQE (Timer Queue 
Elements) that were queued by DECnet were being thrown off by 
the time being set forward or backward. If you thought that was 
bad, you should try it on a 5 node VAXcluster. I not sure if 
they told me that DECnet has its own type of timer queue (if 
that sense). Finally as usually FIXED IN FUTURE RELEASE, 
signed another victim. 

George Walrod 
4260*b chain bridge rd 
fairfax, va 22030 


Note 618.2 $set time and ETHERNET 2 of 2 

"Jamie Hanrahan" 5 lines 30*MAR*1987 16: 20 

*< I thought that was fixed >- 

u m ii x A u u it & a b £% & i& a a ti & * iLti n a. ti u. si * u it, a d & ti * * * a. & u a *3, & a * u u u a a ^ a n a a a *. a a & a 

That problem was supposed to have been fixed under V4.5. (See 
note 574.3 for a more complete discussion.) As far as I can 
tell, it *is* fixed: I tried setting the clock back on our 
MicroVAX a little while ago to see if the problem would occur, 
and all was well... 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619*56541865 
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Note 619.0 unwanted formfeed 1 reply 

"CHUCK MCMICHAEL" 12 lines 304MAR41987 10:11 

Somewhere in VMS 4.x, the print spooler began forcing a formfeed 
before the 1st print job each morning when the VAX is powered 
up. This apparently is to flush the printer's buffer, but when 
the printer has numbered' forms (i.e. checks), this is a royal 
pain. 

Our previous workaround was to print a dummy file before the 
printer itself was turned on. Now that the terminal we use to 
print has been hooked to a DECserver 100, this "solution" works 
randomly 50% of the time. 

Has anyone overcome a similar problem? Is the formfeed coming 
from the symbiont or the job controller? How can we kill it? 

CHUCK MCMICHAEL 
PITTSBURGH CORNING CORP 
800 PRESQUE ISLE DR 
PITTSBURGH PA 15239 
412*327*6100 


Note 619.1 unwanted formfeed 1 of 1 

"Jack Patteeuw" 14 lines 304MAR41987 17:39 

*< So you can draw pretty pictures on them ... >4 

DEC is obviously in "kahutz" with several paper vendors because 
they really love to throw out those <FF>'s I 

My experience is that whenever a Queue is started ($START/QUEUE 
or $INIT/START/QUEUE) the first thing the Print Symbiont does is 
send out a <FF> (this is on a terminal queue). This is not 
documented anywhere that I can find, but we have verified this 
at our site. 

Additionally, if you use SETUP modules and they contain more 
than "standard" escape sequences, the Symbiont will throw a <FF> 
after the SETUP module is transmitted to the printer. This IS 
documented, but I can't think for the life of me why they would 
do such a thing. Now my users with non4DEC laser printers get 


VAX-107 














DECUS PROGRAM LIBRARY 


DECUS PROGRAM LIBRARY CHANGES 

DECUS NO: 11-179, Title: Fast Fourier Transform 
Routine Please note “Documentation available in hard¬ 
copy only”. 

NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PDP-11 COMPUTER FAMILY 

DECUS NO: ll-SP-96 Title: Reese’s PiecesVersion: 
October 1986 

Submitted by: Frank R. Borger, Michael Reese Medical 
Center, Chicago, IL Operating System: IAS V3.2 Source 
Language: FORTRAN 77, FORTRAN IV, FORTRAN 
IV-PLUS, MACRO-11, REESE BASIC Keywords: Util¬ 
ities - IAS 

Abstract: Reese’s Pieces is a collection of programs that 
are used at Michael Reese mostly as operational aids. 
Some are enhancements or additions to IAS functions, 
some are RSX-11M programs updated to operate under 
IAS, some are just fun. 


1,10 

Lots of programs, a catchall account. 

1,12 

The INForm package, updated for 


version 3.2. 

1,16 

DUPLEX and XMIT, updated for IAS 


1.25 COOKIE, DAMMIT, HEADACHE, 
MURPHY and MAY, smart remark 
pgms. 

1.26 Programs to list the external page, 
software used to generate bootstrap 
roms for non standard device ad¬ 
dresses. 

1.30 Programs to help you patch disks, 
examine FCS file structures, show disk 
activity, recover lost files, show file 
attributes. 

1.31 Screen based clock, and system dis¬ 
play. 

1.32 An RSX mail program, updated to 
run on IAS, (Uses Reese style login 
info, but could be adopted to regular 
IAS.) 

1,40 Program to list current FCB’s in use. 

1,2 MRH HELP, help modified to use 

multiple help files, instead of one 
humongous file, so its faster. For a 
command of AID ZAP, help first tries 


to use ZAP.HLP, then defaults to 
MCR.HLP. 

DR1:1,10 Much of the documentation for pack¬ 

ages in 

1,6 Reese’s Pieces errors, aids to process 

error logging reports, and some simple 
on-line diagnostic aids. 

[11,13] Contains the sources to HEL, BYE, 

etc. that were developed to let an MCR 
based system use the protection fea¬ 
tures of a PDX system. Passwords, 
etc. are in the user profile file, with a 
modified version of the protection code. 
Also has same login for batch. (Modi¬ 
fied task image of pdx is included.) 
Also includes a catchall task that does 
some one-line DCL style commands, 
(DIR,PRINT,etc.) 

*.sys Basic programs used to update 
the user profile file. *.bas Programs to 
aid in logging, accounting, etc. pdsupf- 
.virA virgin file, with only SYSTEM 
and SCITERMINAL autostart.dat 
command file for autostarting selected 
users. Note that we still use an older 
format of the PDSUPF.DAT file. 
Contains VTL, a VT100 terminal listing 
program, commands like KED, options 
for viewing 2 files, lots more. 

VAX style directory command, short 
version with multiple entries per line, 
full version with all file attributes. 
351,73 ECR, Editing MCR. MCR with com¬ 

mand line editing, much more. 

Media (Service Charge Code): 2400’ Magnetic Tape 
(PC) Format: BRU 

DECUS NO: 11-865 Title: LOGDIR Version: Vl.l, 
January 1987 


Submitted by: Andreas G. Schindler, Darmstadt, Fed. 
Rep. Germany D - 6100 Operating System: RT-11 V5.1 - 
5.3, TSX+, SHARE Source Language: FORTRAN IV, 
MACRO-11 Memory Required: 8/UKW (overlaid/non- 
overlayed) Software Required: RT-11 Syslib Hardware 
Required: Extended Instruction Set (EIS) Keywords: 
Utilities - Disk - RT-11 

Abstract: LOGDIR is a special directory program de¬ 
signed to give directory listings of nested logical disks 
without mounting them. It provides an ANSI mode for 
use with VT100 like terminals, producing a “tree of files” 
in full screen depiction (similar to the VAX/VMS “Dirtree” 
utility). All directory structured devices that can be 


[ 1 , 100 ] 


351,70 

(term emulators). 

1,22 BRU and DSC tape directory pgms, 351,72 

unknown tape listers, tape copy pro¬ 
grams, our on-line ROLLIN image 
mode disk save pgms. 


accessed via a RT-11 handler are supported (i.e. disks, 
VM:’s and LD:’s). LOGDIR accepts wildcards and a fine 
choice of switches for easy file scanning. Hardcopy output 
on any device is supported as well. The program needs 
about 11KW of memory and has been successfully run 
under RT-ll/SJ/FB/XM, TSX+ and SHARE4-. 

Notes: XM-version provided requiring only 1.5KW of low 
memory. 

Media (Service Charge Code) : OneRX01 Diskette(KA) 
Format: RT-11, 600’ Magnetic Tape (MA) Format: RT- 
11 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

VAX/VMS FAMILY OF COMPUTERS 


DECUS NO: V-SP-61 Title: Symposium Collection from 
the VAX SIG, Fall 1986, San FranciscoVersion: Fall 
1986 


Submitted by: J. L. Bingham, Mantech Services Company, 
Alexandria, VA Operating System: VAX/VMS V4.X 
Source Language: BLISS-32, C, MACRO-32, PASCAL, 
VAX BASIC, VAX FORTRAN Keywords: Symposia 
Tapes - VMS 

Abstract: This submission contains the programs sub¬ 
mitted to the VAX Systems tape copy effort at the Fall 
1986 DECUS U.S. Symposium in San Francisco, Cali¬ 
fornia. The programs have been placed in two major 
backup sets named VAX86C and VAX86D. The following 
is a brief summary of the contents of the collection: 


VAX86C 

[.AKCOUNT] 

[.BCLUG] 

[.BULLETIN] 

[.CENTRAL 

FLORIDA] 

[.CLEMENT] 


[.DUFF] 


[.EDTPLUS] 

[.SYSTEMS] 


VMS chargeback accounting package 
and resource accounter. 

VMS performance monitor system. 
VAX Bulletin Board and Notes Sys¬ 
tem. 

Color representation on the VT-241 
and 

LCP01. Set colors on a VT-241. TPU 
EDT enhancements. 

A set default program, a directory 
wipeout procedure, a spying program, 
Bonner Lab RUNOFF, TPU EDT ex¬ 
tensions. 

STRETCH - performance analysis 
system for capacity planning. Struc¬ 
tured Cluster Management talk com¬ 
mand files. 

Enhanced emulation of EDT in TPU. 
ADA pretty printer. PASCAL pretty 
printer. TeX procedures for unsophis¬ 
ticated users to create memos, contact 
reports, slides, etc. using LaTeX. 


[.FPAINT] 

[.FRANCE] 

[.GAMES. 

CONQUEST] 

[.IIT] 

[.KAZ] 

[.LATSHAW] 

[.MIVAXLUG] 

[.NSWC] 

[.PAGESWAPR] 

[.RIGS] 

[.SEALUG] 

[.SIXTPU] 

[.TPUWPS] 

[.UAB] 

[.UALR] 

[.VIEWRPT] 


[.WKU] 

VAX86D 

[.BIBLE] 

[.BNELSON] 


Data entry manager for use with 
FORTRAN. 

Font editor for LN03 which allows 
you to use TeX type fonts on LN03 (or 
to use fonts from TeX). 

Multiplayer realtime spacewar game 

based 

on Empire. 

Integrated accounting facility for aca¬ 
demic systems. Network print sym¬ 
biont for full function remote printing 
over DECnet. 

EDT and EDT TPU emulator custom- 
izations & docs. 

EDTEM - TPU based editor using 
EDT keypad. Utilities for doing binary 
DEC-IBM and IBM-DEC conversions. 
Image to make a VMSINSTAL-able 
KERMIT. SEE ALL mode for TPU. 
DRAWTREE update. 

SD utility update. Reminder utility 
update. 

Pageswapper articles since last tape. 
Extensions to C library with equiva¬ 
lent of Un*x “system” function and 
some support routines. 
Conversational DECnet link. Netsub- 
mit -submit jobs across net. SWAP 
(become another user) update. 
SIXEL - program to plot ReGIS gra¬ 
phics to sixel files. Program to dump 
to LA100. Additions to EDT interface 
to TPU. 

WPS-PLUS emulation in TPU. 
Foreign Tape processor. ASCII or 
EBCDIC. SMAUG - process to lower 
priority of CPU hogs, raise it again 
when they use less CPU. 

Full function bulletin board system 
for VAX. 

NEWS utility. REMOTE - issue com¬ 
mands across DECnet. SNOOPY - 
continuous user monitor to watch 
what a process is doing. VIE WSYSTEM 
-watch what’s going on on the whole 
system. 

compile, link and execute a program 
in any language. 


Full text (uppercase only) of King 
James Version of the BIBLE (com¬ 
pressed). 

BITNET interface programs, KER- 
MIT-11 Version 3.54, afasttape-disk- 
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[.DTRSIG] 


[.FERMILAB] 


[.FERMLIB] 


tape copy program (VMSTPC), and 
the TED fullscreen editor for VMS 
(native mode), RSX, RSTS, and P/ 
OS. 

DTR defs for ALL-IN-1 logging or 
WPS-PLUS logging. User defined func¬ 
tions including SPAWN and string 
length. Wombat Examiner issues. 
Transcripts of some Symposium ses¬ 
sions. 

EDTX extended EDT. Modified VAX 
C include files for system items not in 
Digital Equipment Corporation dis¬ 
tributed files. 

Device Independent Graphics Systems. 


[.ICON] 


[.LEVINE] 

[.RCAF86] 

[.MISC. 

CSNETITM] 

[.SPELL] 

[.VMSKERMIT] 


This is Version 6.0 for VAX and 5.9 for 
MSDOS of the ICON programming 
language, which is a next generation 
text language with some SNOBOL 
antecedents. 

Includes several packages for reducing 
disk fragmentation. 

AnalytiCalc update (Version 21.2) with 
cell annotation. Update to VMS GNU 
EMACS. 

Various utilities and informational 
items 

from CSnet mail. 

Spelling checker for TPU/EVE, plus a 
standalone version. 

Maintenance release of KERMIT-32. 
This version (3.3.111) fixes several 
bugs and now works correctly with 
FILE TYPE FIXED files with short 
final blocks. 


Notes: Some submitters did not submit sources, most 
did. Many of the filenames violate VMS version 3.x naming 
conventions so you will get RMS errors if you try to load 
the programs on a version 3 system. Since most people 
are on version 4 by now, no attempt has been made to 
make the names compatible with version 3. 

Restrictions: See individual AAAREADME.TXT files. 
Complete sources not included. 

Media (Service Charge Code): 2400’ Magnetic Tapes 
(PB) Format: VMS/BACKUP, TK50 Tape Cartridge (TC) 
Format: VMS/BACKUP 


DECUS NO: VAX-233 Title: Computer Modern Font 
Files and Build Procedures Version: October 1986 

Author: John Sauter 

Operating System: VAX/VMS V4+Source Language: 
DCL Software Required: METAFONT Hardware Re¬ 


quired: Digital Equipment Corporation LN03 Laser 
Printer Keywords: Interface Routines, Utilities - VMS 

Abstract: This is a collection of Computer Font files as 
well as the VMS command procedures which build them 
for use on a Digital Equipment Corporation LN03 laser 
printer using METAFONT device-dependent parameters. 
There are 75 standard fonts in the standard 7 magnifi¬ 
cations, Computer Modern Symbols in 12-point and 
Computer Modern Sans Serif. 

The collection includes the alternative parameter files 
and the resulting .TFM and pixel files for the Digital 
Equipment Corporation LN03. 

Release Notes are distributed with each order. 

Restrictions: Requires two and one-half days CPU time 
on VAX-11/785 to build files. How ever, all files have been 
included. 

Documentation not available. 

Media (Service Charge Code): 2400’ Magnetic Tape 
(PC) Format: VMS/BACKUP 


DECUS NO: VAX-235 Title: CAYENNE Version: 2G.6, 
January 1986 

Submitted by: Digital Equipment Corporation Operating 
System: VAX/VMS Version 4.4 Source Language: FOR¬ 
TRAN 77, MACRO-32 Memory Required: Normal config. 
- more is faster. Keywords: Circuit Simulation 

Abstract: CAYENNE is a parallel version of Berkeley 
SPICE 2G.6, DECUS Part No. VAX-216. It utilizes the 
PlibV2 parallel library routines. The purpose of CAYENNE 
is to run a parallel version of SPICE 2G.6 on any VAX/ 
VMS multi-processor, which at this time includes the 
VAX 8300 and the VAX 8800. CAYENNE will also run on 
a single processor VAX. 

A set of routines which embeds the parallelization 
methodology used for CAYENNE and greatly facilitates 
parallel program development is given in the file CAYEN- 
.FOR. This file along with the files PLIBFOR.FOR and 
PLIBMAC.MAR form the library of routines developed 
for the CAYENNE methodology. 

Two SPICE input files are also in the directory: BJTAD- 
DER.SPI and MOSADDER.SPI. Outputs for these input 
files are: BJTADDERBST.SPO and MOSADDERBST.- 
SPO. These files will verify the CAYENNE application. 

Benchmarking this application on a VAX 8300 MP has 
yielded performance results from 1.5 to over 1.8 times the 
single stream version of SPICE. Results will vary due to 
the size of the data sets. Larger SPICE 2G.6 data sets will 
tend to yield greater performance; hence greater through¬ 
out. 

Several command procedures have been included for 
ease of use. CAYENNE may be run in single stream or as 
a parallel application by specifying the number of sub¬ 


processes desired. The specification of zero subprocesses, 
at start up, would yield a single stream execution of 
CAYENNE, while a specification of two subprocesses 
would be ideal to run CAYENNE in parallel across two 
processors. 

Notes: Two input (demo) files are included as mentioned 
in the read_me.first file. 

Restrictions: U.S. Government export regulations pro¬ 
hibit the distribution of this program outside of the United 
States without the appropriate export licenses. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 


DECUS NO: VAX-238 Title: VMS Disassemblers Pack¬ 
age Version: VI, February 1987 

Author: Claus Calle, Andy Parlin and others 

Operating System: MicroVMS, RSX-11M, VAX/VMS 
Source Language: MAC RO-32, PASCAL, VAX FOR¬ 
TRAN Keywords: Disassemblers 

Abstract: Two VMS disassemblers capable of creating 
MACRO-32 sources from VMS native mode images are 
presented. All sources and brief documents are present, 
and one contains compiled executable code so that it can 
be used by sites without FORTRAN. The disassembler 
so presented is capable of disassembling user mode im¬ 
ages, drivers and other system images reasonably intelli¬ 
gently, but there are areas in which it is incomplete, 
notably not having ALL possible RMS control block 
types recognized separately. 

A few tapecopy VMS utilities and things are also included 
on the tape as a general convenience for users. 

Media (Service Charge Code): 600’ Magnetic Tape (MS) 
Format VMS/BACKUP 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PROFESSIONAL 300 SERIES OF COMPUTERS 

DECUS NO: PRO-166 Title: FSTATS: Statistical Ana¬ 
lysis Package Version: V1.0, January 1985 

Author: Margaret Quince et al., Lincoln College 

Submitted by: Stephen Hirsch, NZAEI, Lincoln College, 
Canterbury, New Zealand 8150 Operating System: RT- 
11 V5.1 Source Language: FORTRAN IV Memory Re¬ 
quired: See Restrictions Hardware Required: EIS, FPU 
Keywords: Mathematical, Professional-300 Series -RT- 
11, Statistics 

Abstract FSTATS is a package of statistical routines 
which can analyze up to 1000 floating point variables in 
up to 100 groups. It includes the following options: 


Data Editor, Wilcoxon’s Matched Pairs Signed Rank 
Test, Fisher’s Exact Prob. Test, T Test Paired, Histogram, 
Linear Regression, One Way Analysis of Variance, 
Graphs of Data, Data Summary, Chi Square Test on I x J 
Contigency Table, Pearson’s Correlation Coefficient, T 
Test Unpaired, Mann Whitney U Test, Spearman’s Rank 
Correlation Coeef., Kruskal-Wallis Analysis of Variance, 
and Transformations of Data. 

Because of it’s size, FSTATS must be linked as a virtual 
job -it’s high limit is 28543 words 4- the OTS work area. It 
can be linked using full high memory overlays which will 
use about 80000 words of memory or using disk overlays, 
this can be reduced to about 32000 words plus the operating 
system. 

This version of FSTATS was originally developed on a 
system running IAS and was converted to run under RT- 
11 on a Professional 325. There are almost certainly 
minor bugs in the program as it has not been used ex¬ 
tensively yet. 

The Inline FORTRAN Compiler was used in program 
development - no responsibility can be taken for successful 
linking if the threaded code compiler is used. 

Restrictions: Program was developed using the FOR¬ 
TRAN Inline Compiler an a 11/23 CPU with EIS and 
FPU. Because of memory allocation problems, there may 
be difficulties using a system with different hardware. 
For memory required, 80000 words or using disk overlays, 
this can be reduced to about 32000 words plus the operating 
system. 

Media (Service Charge Code): One RX50 Diskette 
(JA) 

REVISIONS TO LIBRARY PROGRAMS 

DECUS NO: ll-SP-72 Title: Reese BASIC Version: 
September 1986 

Submitted by: Frank R. Borger, Michael Reese Medical 
Center, Chicago, IL Operating System: IAS V3.2, RSX- 
11M, VAX/VMS V4.2 Source Language: MACRO-11 
Hardware Required: FPP or emulator Keywords: BASIC, 
Language Interpreters, Programming Languages 

Abstract: Reese BASIC is a highly upgraded version of 
what used to be a DECUS library program for DOS. 

. Full FILES-11 I/O is supported, (fixed length random 
access, shared mode, etc.). 

. String functions and user defined functions are much 
more flexible than in either the original version or in 
Digital Equipment Corporation’s BASIC-11. 

. Multi-user implementation is supported with separate 
pure and impure areas (IAS and RSX-11D only). 

. Since it is an interpreter, it includes the special debugg¬ 
ing commands: STEP, CON and SET TRACE. 

. Although an interpreter, significant manipulation of 
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the source program is done to speed up operation. 

. OVERLAY and a data preserving CHAIN are also 
supported. 

. A clean “break” feature is implemented via the TT 
. handler. 

. A number of BASIC-PLUS-2 like features have been 
added including: virtual arrays, integer and byte vari¬ 
ables, continued lines and IF-THEN-ELSE. 

. The capability of SPAWNING another task is sup¬ 
ported. 

Media (Service Charge Code): 600’ Magnetic Tape (MC) 
Format: BRU 

DECUS NO: 11-433 Title: LISP for RSX-11 and Micro/ 
RSX Version: October 1986 

Submitted by: Maximilian Hadersbeck, Ludwigs-Maxi- 
milian-Universitat, 8 Munchen 40, West-Germany Oper¬ 
ating System: Micro/RSX V3.0, RSX-11M V3.2 Source 
Language: MACRO-11 Memory Required: 10-28K Soft¬ 
ware Required: MACRO and the Advanced Programmer 
Kit for Micro/RSX. Keywords: LISP 

Abstract: This version of LISP is written entirely in the 
PDP-11 MACRO by Chris Meyers, Eugene, OR. It has a 
minimum of system calls to make it easy to adapt it to 
other operating systems. 

This revised version works as it is under Micro/RSX 
V1.0, RSX-11 M PLUS V2.1 and RSX-11M V4.1. The de¬ 
livered command files and installation files make it very 
easy to install the LISP system under the previous named 
operating systems. 

With the package, some examples of LISP programs, like 
an algorithm for proving theorems out of the logic - 
calculus (Wang - Algorithm) and the Ackermann function 
are delivered. 

The support programs LINT and SAVLSP written by 
Chris Meyer are also in this package. These were both 
written in FLECS which is a FORTRAN preprocessor. 
The resulting FORTRAN code is also there. LINT is very 
handy to both produce a readable LISP program and to 
eliminate those bugs due to miscounting parans. SAVLSP 
is very system dependent and is running only on an IAS 
system. 

Notes: See 11-347 for the RSTS version of LISP-11. 

Changes and Improvements: New examples and a 
complete new installation. Command-files suited for 
Micro/RSX and RSX. 

Media (Service Charge Code): One RX50 Diskette(JA) 
Format: FILES-11, 600’ Magnetic Tape (MA) Format: 
FILES-11 


Submitted by: Michael M. Iloff, Moses Electronics, 7000 
Stuttgart 1, West Germany Operating System: RT-11 
V5.4 Source Language: MACRO-11 Memory Required: 
582 words Hardware Required: Data I/O System 19 
Universal Programmer 990-1900 Keywords: Device 
Handlers, PROM 

Abstract: This handler was derived from Digital Equip¬ 
ment Corporation’s PC11 high speed paper tape reader 
in order to allow for device-independent execution of file 
and command transfer via PIP.SAV to and from the 
DATA I/O SYSTEM 19 UNIVERSAL PROGRAMMER 
990-1900 via a DLV11-J line at address 176520 and vector 
320. It needs a running line time clock under a system 
generated monitor with device timeout feature for reading 
from the programmer device. 

Notes: The system is generated with a device-timeout 
feature. 

Changes and Improvements: XM bug fixed, address set 
code added plus see PB.MAC header plus adapted to 
V5.4. 

Restrictions: Running line time clock. RT-11 version 5.4 
is required due to new device handler macros. 

Documentation not available. 

Media (Service Charge Code): One RX01 Diskette(KA) 
Format: RT-11, 600’ Magnetic Tape(MA) Format: RT- 
11 


LIBRARY ANNOUNCEMENT 

The Library has the following list of products available on the TK50. Each 
tape (media code TC) sells for $194.00 (U.S. only), and will be treated as a 
regular Library product. 


VAX-LIB-1 VAX LIBRARY TAPE #1 

VAX-LIB-2 VAX LIBRARY TAPE #2 

VAX-LIB-3 VAX LIBRARY TAPE #3 

VAX-LIB-4 VAX LIBRARY TAPE #4 

VAX-LIB-5 VAX LIBRARY TAPE #5 

VAX-SPLIB-1 SPECIAL VAX LIBRARY TAPE #1 
VAX-SPLIB-2 SPECIAL VAX LIBRARY TAPE #2 


V-SP-24 PORTACALC 

V-SP-43 RSX SIG COLLECTION, SPRING '85, NEW ORL. 

V-SP-46 VAX SIG COLLECTION, SPRING ’85, NEW ORL. 

V-SP-48 BEST OF PC-8088 COLLECTIONS 1-8 

V-SP-49 VAX SIG COLLECTION, FALL ’85, ANAHEIM 

V-SP-50 RSX SIG COLLECTION, FALL ’85, ANAHEIM 

V-SP-51 PC-8088 COLLECTION #9 

V-SP-52 VAX SIG COLLECTION, SPRING ’86, DALLAS 

V-SP-53 KERMIT DISTRIBUTION 

V-SP-54 PC-8088 COLLECTION #10 

V-SP-55 RSX SIG COLLECTION, SPRING ’86, DALLAS 

V-SP-58 LATEX, TEX 

V-SP-60 RSX SIG COLLECTION, FALL ’86, SAN FRANCISCO 

V-SP-61 VAX SIG COLLECTION, FALL ’86, SAN FRANCISCO 

11-SP-47 PORTACALC 
11-SP-18 C LANGUAGE SYSTEM 

11-SP-84 RSX SIG COLLECTION, SPRING ’85, NEW ORL. 

11-SP-90 RSX SIG COLLECTION, FALL ’85, ANAHEIM 
11-SP-92 RSX SIG COLLECTION, SPRING ’86, DALLAS 
11-SP-95 RSX SIG COLLECTION, FALL,’86 SAN FRANCISCO 


* AVAILABLE AT THE NASHVILLE SYMPOSIUM LIBRARY BOOTH 


BOLDED PRODUCTS ARE NEW ANNOUNCEMENTS AVAILABLE ON THE TK-50. 


DECUS NO: 11-665 Title: PB: Device Handler for Data 
I/O System 19 Prom Programmer Version: March 1987 


CALL 617-480-3418 TO ORDER THESE PRODUCTS, MOST CREDIT CARDS 
ACCEPTED 
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SUBMITTING ARTICLES TO THE HMS SIG NEWSLETTER 


The purpose of the HMS SIG newsletter is to serve as a forum 
to share information related to DEC hardware with the 
members of the SIG. As such, the existence of the 
newsletter is entirely dependent on your contributions. If 
you have an HHK item, a better or safer way to do something, 
product news, a tutorial article of general interest, etc., 
we are interested in publishing it in the newsletter. It is 
intended that the HMS newsletter be published at least four 
times a year. 

You can submit material to either the editor. Bill Walker, 
or the assistant editor. Carmen Wiseman. We can accept sub¬ 
missions in a wide variety of formats: 


o Items can be sent to the assistant editor on VMS 

format RX50s or IBM PC format 5 1/4" floppies. 

o The editor can handle just about any reasonable 
media, but prefers RT-11 format diskettes. 

o Hard copy, like cash, is always acceptable. If it 
is camera-ready it will save us a lot of typing, 
but we don't insist on it. You can also use the 
"Hardware Submission Form," which you will find in 
the "Questionnaire" section of the combined 
newsletters. 

o Those of you that have access to DCS can send 

things to WALKER or WISEMAN. DCS is usually 

checked on a daily basis. 

o You can reach the editor on CompuServe as 

"Bill Walker 71066,24" or via EasyLink mailbox 
62752448. You can reach the assistant editor via 
EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the message). 


In any event, if you have anything to submit, send itl If 
it is a mess, but we can read it, we will get it in the 


newsletter somehow. Finally, 
submitting material, call one 
are listed below. 

Contributions can be sent to: 

William K. Walker 
Monsanto Research Corp. OR 

P.O. Box 32 A-152 == 

Miamisburg, OH 45342 
(513) 865-3557 (work) 

(513) 426-7094/0344 (home) 


if you have any question about 
of us. The telephone numbers 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 
(617) 375-4361 
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DECUS 


DECUS U.S. CHAPTER 

SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM 

(U.S. Members Only) 


As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly pub¬ 
lication, SIGs Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a 
compilation of the reports from various speakers at the U.S National DECUS Symposia 


e No Purchase Orders will be accepted. 

e The order form below must be used as an invoice 
e All checks must be made payable to DECUS 
e All orders MUST be paid in full 

e Minimum of $25.00 for orders placed via a credit card, 
e No refunds will be made. 

eThe address provided below will be used for all DECUS mailings; Le. Membership Subscription Service and 
Symposia 

• SIGs Newsletters Price is for a one-year subscription beginning the month following receipt of payment 


Name_DECUS Member# 

Company_ 

Address_ 


City_State_Zip 

Telephone # __i_ \ _ 


Subscription Service Offering Unit Price Qty Total 

SIGs Newsletters $35.00 _ _ 

Spring’86 Proceedings (SP6) 15.00 __ _ 

Fall’86 Proceedings(FA6) 15.00 _ _ 

Spring’87 Proceedings(SP7) 15.00 _ _ 

Fall’87 Proceedings (FA7) 15.00 _ __ 


Total Amt $- 

□ MASTERCARD □ VISA □ DINERS CLUB/CARTE BLANCHE® 

Credit Card#____Expiration Date 


I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature___-—-— - 

For Digital Employees Only 

Badge #_Cost Center_ 

Cost Center Mgr. Name_ Cost Center Mgr. Signature- 

MAIL TO: Subscription Service, DECUS(BP02), 219 Boston Post Road, Marlboro, MAOI752-1850, (617)480-3418. 


FOR DECUS OFFICE ONLY 

Check Number _ Bank Number - 

Amounts _ 
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DECUS U.S. CHAPTER 
APPLICATION FOR MEMBERSHIP 



DECUS 


□ New Membership □ Update to current membership profile Current DECUS Member.#_ 

Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality. 

Are you an employee of Digital Equipment Corporation? □ YES □ NO 


NOTE: Please print clearly or type! 


Name:_ 

(First) (Middle Initial) (Last/Family Name) 

Company:_ 

Address:_ 


i 

I- 

j City/Town/State/Zip: 


S Telephone: Home( ) _ Work( ) 

i 

S How Did You Learn About DECUS? Please Check Applicable Item. 


1 □ 

ANOTHER DECUS MEMBER 

4 □ DIGITAL SALES 

13 □ 

LOCAL USERS GROUP 

2 □ 

SYMPOSIA 

5 □ HARDWARE PACKAGE 

14 □ 

SPECIAL INTEREST GROUP 

8 □ 

DECUS CHAPTER OFFICE 

6 □ SOFTWARE PACKAGE 

7 □ 

SOFTWARE DISPATCH (Digital Newsletter) 

10D 

DIGITAL STORE 

12 □ ADVERTISING 




i 


Do you wish to be included in mailings conducted by Digital (for marketing purposes etc?) □Permission 

□ Refusal 

Type Of Digital Hardware Used: Please Check Those Applicable To You. 


20 □ 

DECMATE 


52 □ LSM 1 


21 □ 

PROFESSIONAL 5 0 

WPS-8 


82 □ 

DECSYSTEM-10 

3 □ PD P-8 FAMILY 

22 □ 

RAINBOW 

51 □ 

WPS-11 


83 □ 

DECSYSTEM-20 

50 □ PDP-11 FAMILY 

54 □ 

VAX FAMILY 




B 

1 Major Operating Systems? Languages Used: 

Please Check Those Applicable To You. 



lD 

ADA 

26 □ 

CORAL-66 

47 □ 

FOCAL 

67 □ 

OS/8 

109 □ 

RT-11 

S 2D 

ALGOL 

28 □ 

COS 

48 □ 

FORTRAN 

68 □ 

PASCAL 

97 □ 

TECO 

l 50 

APL 

34 □ 

DATATRIEVE 

51 □ 

GAMMA 

72 □ 

PL-11 

70 □ 

TOP&IO 

1 ?□ 

BASIC 

35 □ 

DBMS 

noD 

IAS 

92 □ 

RPG 

71 □ 

TOPS-20 

■ 17 □ 

BLISS 

38 □ 

DECNET 

53 □ 

IQL 

81 □ 

RSTS/E 

111 □ 

ULTRIX/UNIX 

j 19 □ 

C 

43 □ 

DIBOL 

58 □ 

MACRO 

83 □ 

RSX 

104 □ 

VMS 

! 22 □ 

■ 

■ 

COBOL 

45 □ 

DOS-11 

65 □ 

MUMPS 

91 □ 

RMS 

107 □ 

WPSr8 
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Type Of Business (Environment)/Computer Applications 

Please Check That Which Best Describes Your Business/Application. 


21 □ 

ACCOUNTANCY 

i □ 

EDUCATION/PRIMARY 

23 

NUMERICAL CONTROL 

7 □ 

BANK 

20 

EDUCATION/SECONDARY 

68 □ 

OEM-COMMERCIAL 

64 □ 

BUSINESS/COMMERCIAL 

61 □ 

EDUCATION-TECHNOLOGY 

78 □ 

OEM-TECHNICAL 

| 74 □ 

BUSINESS/INFORMATION SYSTEMS 

3 G 

EDUCATION/UNIVERSITY 

56 □ 

PHYSICAL SCIENCES 

57 □ 

CHEMISTRY 

67 □ 

ENGINEERING 

20 □ 

RESEARCH/DEVELOPMENT 

54 □ 

CLINICAL LABORATORY 

65 □ 

FINANCE/ACCOUNTING 

10D 

RETAIL 

63 □ 

COMPUTATION 

77 □ 

GOVERNMENT 

73 □ 

SOFTWARE DEVELOPMENT 

11 □ 

CONSUMER ELECTRONICS 

75 □ 

GRAPHICS 

53 □ 

TELECOMMUNICATIONS 

j 18 □ 

CONSULTANT 

4 □ 

HOSPITAL 

19 □ 

TELEPHONE/UTILITIES 

| 72 □ 

DATA ACQUISITION 

62 □ 

INDUSTRIAL 

51 □ 

TIMESHARING 

| 52 □ 

DATA COMMUNICATIONS 

55 □ 

LABORATORY/SCIENTIFIC 

80 □ 

TRAINING/INSTRUCTION 

! 13D 

DATA PROCESSING SERVICES 

14 □ 

LIBRARY 

66 □ 

TYPESETTING/PUBLICATION 

( 71 □ 

DATA REDUCTION 

58 □ 

LIFE SCIENCES 



l 17 □ 

DIGITAL EMPLOYEE-ENGINEERING 

70 □ 

MANUFACTURING 



[ 15 □ 

DIGITAL EMPLOYEE-MARKETING 

79 □ 

MARKETING 



I 16 □ 

DIGITAL EMPLOYEE-SERVICE GROUP 

59 □ 

MEDICAL RESEARCH 



\ 60 □ 

EDUCATIONAL ADMINISTRATION 

6 □ 

MILITARY INSTALLATION 




Special Interest Groups(SIGs) Enrollment 

I Wish To Participate In The Following DECUS U. S. Chapter Special Interest Groups. 


5 3 □ 

ARTIFICIAL INTELLIGENCE 

ii □ 

HARDWARE AND MICRO 

36 □ 

PERSONAL COMPUTED 

\ 7D 

BUSINESS APPLICATIONS 

35 □ 

IAS 

18 □ 

RSTS/E 

| 20 

COMMERCIAL LANGUAGES 

27 □ 

LARGE SYSTEMS 

17 □ 

RSX 

| 6 □ 

DATA MGMT SYSTEMS 

16 □ 

L& T 

19 □ 

RT-11 

j 31 □ 

DAARC (LABS) 

14 □ 

MUMPS 

32 □ 

SITE MGMT & TRNG 

i 5 □ 

i 

DATATRI EVE/4 GL 

15 □ 

NETWORKS 

21 □ 

UNISIG 

| 80 

EDUSIG 

34 □ 

OFFICE AUTOMATION 

26 □ 

VAX 

■ ion 

GRAPHICS APPLICATIONS 






Job Title/Position - Please Check: 


■ 1 □ CORPORATE STAFF 

■ 20 DIVISION OR DEPARTMENT STAFF 
S 3 □ SYSTEMS ANALYSIS 

| 4 □ APPLICATIONS PROGRAMMING 

• 5 □ SYSTEMS ANALYSIS/PROGRAMMING 

• 6 □ OPERATING SYSTEM PROGRAMMING 

5 7 □ DATABASE ADMINISTRATION 

| 8 □ DATA COMMUNICATIONS/TELECOMMUNICATIONS 
{ 9 □ COMPUTER OPERATIONS 

5 10D PRODUCTION CONTROL 

| Citizen of The United States of America? □ YES □ NO 


101 □ 
102 □ 

103 □ 

104 □ 

10&D 

loeD 

107D 

iobD 

109 □ 

110D 

Country;_ 


CORPORATE DIRECTOR OF DP/MIS 

ADMINISTRATIVE ASSISTANT 

TECHNICAL ASSISTANT 

SERVICES COORDINATOR 

MANAGER 

ANALYST 

PROGRAMMER 

DATABASE MANAGER 

DATABASE ADMINISTRATOR 

MANAGER OF DP OPERATIONS 


■ 

| Signature;_Date:. 

{ Forward To: DECUS U. S Chapter 
2 Digital Equipment Computer Users Society 

• Membership Processing Group 

S 219 Boston Post Road, BP02 

• Marlboro, MA 01752-1850 

S Phone: (617)480-3418 

J DTN: 8-296-3418 
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STEERING COMMITTEE LISTS 



ARTIFICIAL INTELLIGENCE SIG 

CHAIR 

Cheryl Jalbert 
JCC 

128 West Broadway 
Granville OH 43023 
(614) 587-0157 

VICE-CHAIR 

OPS5 WORKING GROUP CHAIR 

Don Rosenthal 
Space Telescope Science Inst 
Homewood Campus 
Baltimore MD 21218 
(301) 338-4844 

NEWSLETTER TASK FORCE CHAIR 
ADMINISTRATIVE ASSISTANCE 

Becky Wise 
Amdalh CSD 

2200 North Greenville Ave 
Richardson, TX 75081 
(214) 699-9500 x 272 
NEWSLETTER EDITOR 
Terry Shannon 
Digital Review 
Prudential Tower 
800 Boylston St Suite 1390 
Boston, M A 02199 
(617) 375-4321 

SYMPOSIA COORDINATOR 

Pam Vavra 

Hughes Aircraft EDSG 
P.O. Box 902 E52/D220 
El Segundo, CA 90245-0902 
(213) 616-7071 

MEMBERSHIP COORDINATOR 
SUITE COORDINATOR 

Chris Goddard 
Simpact Associates 
9210 Skypark Court 
San Diego, CA 92123 
(619) 565-1865 

SESSION NOTE EDITOR 

George Humfeld 
Naval Sea Systems Command 
PMS 350 ED Dept of the Navy 
Washington, DC 20362-5101 
(202) 692-0137 

ASS’T SESSION NOTES EDITOR 

David Frydenlund 
STORE REPRESENTATIVE 
Sally Townsend 
Inst Defense Analysis 
1801 N. Beauregard St 
Alexandria, VA 22311 
(703) 845-2122 
PSS REPRESENTATIVE 
Tom Viana 

PUBLIC DOMAIN SOFTWARE TF CHAIR 

Jim Sims 

SITE COORDINATOR, NASHVILLE 

Dennis Clark 

REPORTER TO THE UPDATE. DAILY 

Bill Lennon 

DEC COUNTERPART 
Art Beane 
Hudson, MA 

MEMBERS-AT-LARGE 

David Slater 
George Winkler 
Jeff Fox 

John Williamson 
Wayne Graves 
Matt Mathews 



BUSINESS APPLICATIONS SIG 

CHAIRMAN 

George Dyer 

Gallaudet University 

800 Florida Ave; NE-EMG Bldg 

Washington, DC 20002 

(202) 651-5300 

COMMUNICATIONS REPRESENTATIVE 
SESSION NOTE EDITOR 
STORE REPRESENTATIVE 
NEWSLETTER EDITOR 

Steve Lacativa 
Price Waterhouse 
153 East 53 rd Street 
New York. NY 10022 
(212) 371-2000 x3107 
SYMPOSIA COORDINATOR 
Steve Simek 
IRT Corporation 
3030 Callan Road 
San Diego, CA 92121 
(619) 450-4343 

LRP AND MARKETING COORDINATOR 

Arnold I Epstein 
D-M Computer Consultants 
Rolling Meadows, IL60008 
(312) 394-8889 

LIBRARY REPRESENTATIVE 

David Hittner 
Projects Unlimited 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 
CL SIG LIAISON 

Becky Burkes-Ham 

DMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE 

Robert D. Lazenby 
Dixie Beer Dist, Inc 
Louisville KY 
Robert Kayne 
Gallaudet College 
Washington, DC 
Ray Evanson 
Paragon Data Systems 
Winona. MN 

DEC COUNTERPARTS 

Sue Yarger 
Merrimack, NH 
Ray Arsenault 
Merrimack, NH 



COMMERCIAL LANGUAGES SIG 

CHAIR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd„ Suite 206 
San Jose, CA 95134 
(408) 434-6636 

SYMPOSIA COORDINATOR 

Ray Strackbein 
Palm Desert, CA 
LIBRARY COORDINATOR 
Philip Hunt 
System Industries 
Milpitas, CA 


COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 

SESSION NOTE EDITOR 
Bob Van Keuren 
Userware International, Inc 
2235 Meyers Avenue 
Escondido, CA 92025 
(619) 745-6006 

ASS’T NEWSLETTER EDITORS 
Beverly Welbome 
Diocese of Gary 
LaPorte IN 
Kevin Cullen 
VITA-Mix Corp. 

Holmstead Falls, OH 
Daniel Cook 

Userware International, Inc 
Escondido; CA 

BASIC Working Group Members 
Mark Hartman 
Jadtec Computer Group 
Orange CA 
Rocky Hayden 
Userware International, Inc 
Escondido; CA 
Bill Tabor 
Computer Products 
Pompano Beach, FL 
Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 

COBOL WORKING GROUP MEMBERS 

Keith Batzel 
Crowe Chizek& Ca 
South Bend, IN 
MaryAnne Feerick 
RDBS Inc 
Kernersville NC 
Bill Leroy 

The Software House Inc 

Atlanta, GA 

Herbert J. Matthews IV 

ManTech international Cor. 

Alexandria, VA 

Jim Welbome 

Crowe Chizek& Ca 

South Bend, IN 

Jim Wilson 

Pfizer Inc QC Div. 

Terre Haute IN 

DIBOL WORKING GROUP MEMBERS 

Neil Baldridge 
CompuShare 
Lubbock, TX 
Becky Burkes-Ham 
Colin Chambers 
Software Ireland Rep Inc 
Portola Valley, CA 
Mark Derrick 
WAAY-TY 
Huntsville AL 
Gary A P. Kohls 
Milwaukee WI 
Ken Lidster 
Disc 

Sacramento, CA 
Kenneth M. Schilling 
MCBA 

Montrose CA 
Marty Schultz 
Omtool Inc 
Tewksbury, MA 
Marty Zergiebel 
The Software Gallery 
Brookfield, CT 
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RPG WORKING GROUP MEMBERS 

Keith Batzel 
Crowe Chizek& Co. 

South Bend, IN 
DEC COUNTERPARTS 
Tom Harris 
Nashua, NH 
Jim Totten 
Nashua NH 
Joe Mulvey 
Nashua NH 
Shirley Ann Stern 
Nashua NH 

STANDARDS REPRESENTATIVES 
BASIC 

Dan Esbensen 
Touch Technologies, lne 
Escondido, CA 

COBOL 

Bruce Gaarder 
Macalester College 
St Paul MN 

DIBOL 

Eli Szklanka 
TEC 

Newtoa MA 



DA ARC SIG 

CHAIRMAN 

James Deck 

Inland Steel Research Lah 
8001 East Columbus Drive 
East Chicago, IL 46812 
(219) 892-5613 

SYMPOSIA COORDINATOR 

Mack Overton 
FDA 

Chicago, 1L 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Ellen Reilly 
William H Rorer 
500 Virginia Drive 
Ft Washington, PA 19034 
(215) 628-6547 
DEC COUNTERPART 
Nancy Kilty 
Marlboro, MA 

HARDWARE & INTERFACING 

Peter Clout 

Los Alamos National Lab 
Los Alamos, NM 

MATH STATISTICS & ANALYSIS 

Herbert J. Gould 

CC. F. A Univ. ofllL Medical Ctr. 

Chicago, IL 

PROCESS CONTROL-INDUSTRIAL AUTOMATION 

Bill Tippie 

Kinetic Systems Corp. 

Lockport IL 

RS-1 

George Winkler 
CPC International 
Argo, IL 



DATA MANAGEMENT SYSTEMS SIG 

CHAIRMAN 

Joseph F. Sciuto 
Army Research Institute 
5001 Eisenhower Ave 
Alexandria, VA 22333 

(202) 274-8221 
COMPTROLLER 

Alan Schultz 

Land Bank National DP Center 
7300 Woolworth Ave 
Omaha, NE 68124 
(402) 397-5040 

SYMPOSIA COORDINATOR 

Keith Hare 
JCC 

P.O. Box 463 
Granville; OH 43023 
(614) 587-0157 

SYMPOSIA COORDINATOR 

Barbara Mann 
TRW 

Redondo Beach, CA 
(213) 532-2211 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Mark & Crego 
Mantech Int’l Corp. 

2121 Eisenhower Ave 
Alexandria VA 22314 
(703) 838-5677 

SESSION NOTE EDITOR 

Mark Morgan 
Farm Credit Banks 
P.O. Box 141 
Springfield MA 01102 
(413) 732-9721 

MEMBERSHIP COORDINATOR 

Vacant 

PRODUCT DIRECTION COMMITTEE 
PAST SIG CHAIRMAN 

Steve Pacheco 
Ship Analytics 
North Stonington, CT 06359 

(203) 535-3092 

WORKING GROUP COORDINATOR/ 
DATABASE WORKING GROUP 

Jim Perkins 
PSC, Inc 

20 Kimball Ave, Suite 305 
Shelburne; VT 05401 
(802) 863-8825 

FORMS WORKING GROUP 
ANSI STANDARDS COORDINATOR 
Paul W. Plum, Jr 
Lukens Steel Company 
Coatesville, PA 
(215) 383-2024 

NON-DIGITAL WORKING GROUP 

Doug Dickey 

GTE Government Systems 
1700 Research Blvd 
Rockville MD 20850 
(301) 294-8400 

RMS WORKING GROUP COORDINATOR 

Allen Jay Bennett 
Lear Siegler Rapistan 
555 Plymouth N.E. 

Grand Rapids, MI 49505 
(616) 451-6429 

PRE-SYMPOSIUM SEMINAR COORDINATOR 
Rocky Hayden 
Userware International 
Escondido, CA 
(619) 745-6006 


AI SIG LIAISON 

David Slater 

Institute for Defense Analysis 
Alexandria VA 
(703) 845-2200 

DATATRIEVE SIG LIAISON 

William L Tabor 
W.L Tabor. Inc 
('■oral Springs, FL 
(305) 755-7895 
DEC COUNTERPART 
Wendy Herman 
Nashua NH 
(603) 881-2494 



DATATRIEVE/4 GL SIG 

CHAIRMAN 

Joe H. Gallagher 
Research Medical Center 
2316 East Meyer Blvd 
Kansas City, MO 64132 
(816) 276-4235 
PAST SIG CHAIRMAN 
Larry Jasmann 
U.S. Coast Guard 
10067 Marshall Pond Rd 
Burke VA 22015 

(202) 267-2626 

SYMPOSIA COORDINATOR 

T.C. Wool 

E.I. duPont DeNemours & Co. 
Engineering Dept. 

P.O. BOX 6090. 

Newark, DE 19714-6090 

SPEC. CONSULT. SYMPOSIA 

Diane Pinney 
Naval Weapons Center 
Code 3142 

China Lake, CA 93555 
(619) 939-5112 
(619) 939-5959 

COMMUNICATIONS REPRESENTATIVE 

NEWSLETTER EDITOR 

LRRP 

Donald E Stern, Jr. 

Warner Lambert Company 
10 Webster Road 
Milford CT 06460 

(203) 783-0238 
ASSOCIATE EDITOR 

Steve Cordiviola 
Kentucky Geological Survey 
311 Breckinridge Hall 
Lexington, KY 40506 
(606) 257-5863 

ASST. VOLUNTEER COORDINATOR 

Susan Krentz 
NKF Engineering 
12200 Sunrise Valey Dr. 

Reston, VA 22091 
(703) 620-0900 

PRE-SYMPOSIA SEMINARS 

Dana Schwartz 
15719 Millbrook Lane 
Laurel MD 20707 
(301) 859-6277 

SESSION NOTES EDITOR 

Wanda Anderson 
SRI International MS: pN341 
333 Ravenswood Avenue 
Menlo Park CA 94025 
(415) 859-2577 
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CAMPGROUND 

Bert Roseberry 
Commandant (G-APA-1) 

2100 2nd Street SW. 

Washington, DC 20593-0001 
(202) 267-2629 
WW EDITOR 
PIR COORDINATOR 
LRRP 

Philip A Naecker 
Consulting Engineer 
3011 N. Mount Curve Ave 
Altadena, CA 91001 
(818) 791-0945 
DEC COUNTERPARTS 
DATATRIEVE 

Andy Schneider 
Nashua, NH 
RALLY,TEAM DATA 
Basil Harris, Jr. 

Nashua, NH 

ASSOCIATE SYMPOSIA COORD. 

JUDY Martin 

China Lake Naval Weapons Ctr. 
China Lake CA 93555 

ASS‘T SYMPOSIA REPRESENTATIVE 

Lisa M Pratt 
Vitro Corporation 
Nuwes Code 3144 
Keyport, WA 98345 
(206) 396-2501 
LIBRARY ARTIST REP. 

Bart Z. Lederman 

LT.T. World Communications 

67 Broad Street (28th Floor) 

New Yor, NY 10004 
(212) 607-2657 

POWERHOUSE W/G CHAIR 

Randall R Barth 
Searle Research & Develop 
4901 Searle Parkway 
Skokie IL 60077 
(312) 982-7671 

MEMBER LRPP COMMITTEE 

Michael G. Graham 
Sanders Associates, Inc 
NAM 3-1, C & 2044 
Nashua, NH 03061-2004 
(603) 855-5206 
ASSOCIATE EDITOR 
Janet A Evenson 
Vitro Corporation 
Nuwes Code 3144 
Keyport WA 98345 
(206) 396-2501 

DMS& CLSIG LIAISON 

William Tabor 
Computer Products 
Pompano Beach, FL 



EDUSIG 

CHAIRMAN 

Robert AShive Jr. 

Millsaps College 
Jackson, MS 39210 
(601) 354-5201 

SYMPOSIA COORDINATOR 

Mary Jac Reed 

Off Comp Based Instruction 

University of Delaware 

305 Willard Hall 

Newark. DE 19716 

(302) 451-8161 

COMMUNICATIONS REPRESENTATIVE 

Robert W. McCarley 
Millsaps College 
Jackson. MS39210 
(601) 354-5201 


NEWSLETTER EDITOR 

Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft CA 93267 
(805) 763-4282 
PSS COORDINATOR 
VAX SYSTEMS S1G LIAISON 
Donald (1 Fuhr 
Tuskegee Institute 
Tuskegee Institute A1,36088 
(205) 727-8242 

ADMINSTRATIVE APPLICATIONS COORD. 

Dave Cothrun 
Taft College 
29 Emmons Pk Drive 
P.O. Box 1437 
Taft CA 93268 
(805) 763-4282 

SESSION NOTE EDITOR 

Paula Barnes 
Guilford College 
5800 West Friendly Avenue 
Greensboro, NC 17410 
(919) 292-5511 
DEC COUNTERPART 
Gary Finerty 
Marlboro, MA 



DECUS 


Graphics 

Applications 


GRAPHICS APPLICATIONS SIG 

CHAIRMAN 

William Kramer 

NAS Systems Engineering Branch 
NASA Ames Research Center 
Moffett Field, CA 94035 
(415) 694-5189 

SYMPOSIA COORDINATOR 

Bijoy Misra 

Smithsonian Institution 
60 Gordon St, MS39 
Cambridge MA 02138 
(617) 495-7392 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Michael Anton 
Schlumberger 
P.O. Box591293 
Houston, TX 77259-1293 
(713) 928-4838 

ASSOCIATE NEWSLETTER EDITOR 

Charles D. Carter 
Huntington Alloys, Inc 
Technology Dept 
P.O. Box 1958 
Huntingtoa WV 25720 

(304) 526-5721 

WORKSTATION WORKING GROUP COORD. 

Bob McCormick 
Video Communicationa Ine 
1325 Springfield Street 
Feeding H ilia MA 01030 
(413) 786-7955 

ENGINEERING GRAPHICS WORKING GROUP COORD. 
Eric Rehm 
Gonzaga University 
SPOCAD 
E 502/Boone 
Spokane WA 99258 
(509) 484-6814 

SESSION NOTE EDITOR 

Carol Schwob 
Florida Altantic University 
Academic Computing 
500 N.W. 20th Street 
Boca Raton, FL 33431 

(305) 393-2640 


LIBRARY COORDINATOR 

Mike McPherson 
Michigan University 
269 Engineering Bldg. 

East Lansing, MI 48824 
(517) 353-9769 

STANDARDS COORDINATOR 
Jim Flatten 
Ames Lab 
2581 Metals Dev. 

Amea IA 50011 
(515) 294-7908 

VOLUNTEER COORDINATOR 
Dick McCurdy 
University of Florida 
Room 216, Larsen Hall 
Gainsville FL 32611 
(904) 392-4915 
URRARY COMMITTEE 
James M Turner 
Saber Technology 
San Jose CA 
PEC COUNTERPART 
Rick Berzle 
Spit Brook, NH 

INFORMATION OFFICER 

Mike York 

Boeing Computer Services 
P.O. Box24346 M/S03-73 
Seattle WA 98124 
(206) 342-1442 

HUMAN INTERFACE WORKING GROUP COORD. 

Dottie Elliott 
Northrop Services Ine 
P.O. Box 12313 

Research Triangle PK NC 27709 
(919) 541-1300 

DATA DISPLAY WORKING GROUP COORD. 

Joy Williams 
Eaton Corp. 

P.O. Box766 
Southfield, MI 48037 
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HARDWARE MICRO SIG 

CHAIRMAN 

VAX SIG LIAISON 
TbomasJ. Provost 
MIT/LNS Bates Linac Facility 
Middletown, MA 

PRODUCT PLANNING COORDINATOR 
George Hamma 
Synergistic Technology 
Cupertino CA 

SYMPOSIA COORDINATOR 
PRE-SYMPOSIUM SEMINAR COORDINATOR 
Mike Allen 

Lawrence Livermore Natl Lab. 

Livermore CA 

COMMUNICATIONS COORDINATOR 

John G Hayes 
Information Systems 
South Central Bell 
Birmingham, AL 

NEWSLETTER EDITOR 
William K. Walker 
Monsanto Research Corp. 

Miamisburg, OH 
ASSISTANT EDITOR 

Carmen D. Wiseman 
Digital Review 
Boston, MA 

SESSION note editor 
DAARC SIG LIAISON 
Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 


SIC-3 






STANDARDS COORDINATOR 

CAMAC WORKING GROUP COORDINATOR 

Peter Clout 

Los Alamos National Lab 
los Alamos, NM 
LUG COORDINATOR 
Gregg Giesler 
Los Alamos Science Lab 
Los Alamos, NM 
TOEM (CHIPS & BOARDS) 

JackJ. Peterson 
Horizon Data Systems 
Richmond, VA 

HHK( HARDWARE HINTS & KINKS) 

Wayne Kesling 
Monsanto Research Cor. 

Miamisburg. OH 

UNIBUS HARDWARE 
Ron Bogue 

LIV Aerospace & Defense Co. 

Dallas, TX 

PERFORMANCE MEASUREMENT COORD. 
William Wallace 
600 W. Washington Street 
Peoria, IL 

CSS COORDINATOR 

Pratap Gohel 
EL duPont 
Ingleside; TX 

NETWORKS SIG LIAISON 
Sandra Traylor 
Target Systems 
Yorba Linda, CA 
VAX SIG LIAISON 
Dave Schmidt 
5100 Centre Avenue 
Pittsburgh, PA 
UNISIG LIAISON 

Jim Livingston 
1 Results Way 
Cupertino, CA 
SITE SIG LIAISON 
Emily Kitchen 
A H Robins Ca 
Richmond, VA 
RT-11 SIG LIAISON 
Gary Sallee 

Sallee Software Consulting 
yorba Linda, CA 
RSX SIG LIAISON 
Hans Jung 
Associated Press 
New York, NY 
MEMBERS-AT-LARGE 
Mike Rembis 
American Dade 
Costa Mesa, CA 
Hans Dahlke 
Richland, WA 
Jim Cutler 
EDS Tower 
16533 Evergreen 
Southfield, MI 

DEC COUNTERPARTS TERMINALS 
Nina Abramson 
Maynard, MA 
TOEM (Chips & Boards) 

Art Bigler 
Marlboro MA 
DIAGNOSTIC 

George D. Cooke 
Maynard, MA 
STORAGE 

Marilyn Fedele 
Maynard, MA 

MSD (Micro Systems Develp.) 

Roy Rodgers 
Maynard, MA 
PRINTER PRODUCTS 
Frank Orlando 
Maynard, MA 

DECUS EUROPE LIAISON 

Hans Zoller 


IAS SIG 

CHAIRMAN 

Mike Robitaille 
Grumman- CTEC, Inc 
6862 Elm Street 
McLean, VA 22101 
(703) 556-7400 x 431 
NEWSLETTER EDITOR 
Frank R Borger 
Radiation Therapy 
Michael Reese Medical Center 
Lake Shore Drive @ 31st St 
Chicago IL 60616 
(312) 791-2515 

WHIMS COORDINATOR 

Kathleen Anderson 
Eaton Information Management 
System Division 
Hampton, VA 
(804) 326-1941 
RSX LIAISON 

Ray French 

Boeing Computer Services 
Seattle WA 
(206) 655-6228 
MEMBER-AT-LARGE 
Doug Reno 
Abbot Laboratories 
North Chicago IL 
(312) 937-7504 

CHAIRMAN EMERITUS 

Bob Curley 

Division of Medical Physics 
University of Pennsylvania 
Philadelphia, PA 
(215) 662-3083 

SYMPOSIA COORDINATOR 
Lynda L Roenicke 
Special Systems Branch 
Naval Ocean Systems Center 
271 Cataline Blvd Code 742 
San Diego, CA 
(619) 225-7569 

LIBRARY COORDINATOR 

Bob Schuldt 
INCO Inc 
McLean, VA 

MEMBER-AT-LARGE 

Kerry Wyckoff 
Salt Lake City, UT 
DEC COUNTERPART 

Nancyfaye Autenzio 
Stow, MA 
(617) 496-9606 


Leverage 



LANGUAGES AND TOOLS SIG 

CHAIRMAN 

PROMOTIONS COORDINATOR 
36-BIT COORDINATOR 
Sam Whidden 

American Mathematical Society 
201 Charles St 
P.O. Box 6248 
Providence RI02940 
(401) 272-9500 
VICE CHAIR 

SYMPOSIA COORDINATOR 

Earl Cory 
Eaton Corporation 
31717 Latienda Dr. 

Westlake Village CA 91359 

(818) 70« 


COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 

Howard Holcombe 
RCA 

Front & Cooper Sts. 

Camden, NJ 08055 
(609) 338-4946 
NEWSLETTER EDITOR 
A1 Folsom, Jr. 

Fischer & Porter Co. 

E County Line Rd. 

Warminster, PA 18974 
(215) 674-7154 

SESSION NOTES EDITOR 
Mark Katz 

GTE Government Systems 
100 First Avenue 
Waltham, MA 02154 
(617) 466-3437 
UNISIG INTERFACE 
Mark Bartelt 

HSC - Research Development Ctr 
555 University Avenue 
Toronto, Ontario, Canada M5G1X8 
(416) 598-5955 

AUSTRALIAN L&T INTERFACE 
Gordon Brimble 
Bldg 180 Labs Area 
Defence Research Centre 
Box 2151 GPO 

Adelaide; SA Australia 5001 
(61)(8)259-6119 
GAPSIG INTERFACE 
Jim Flatten 
Ames Lab 
304 Metallurgy 
Ames, IA 50001 
(515) 294-4823 

INTERSIG COORDINATOR 

Dorothy Geiger 
Wollongong Logistics Group 
49 Showers Drive #451 
Mountain View, CA 94040 
(415) 962-7160 
EUROPEAN METHODS 
L&TINTERFACE 
Bemd Gliss 
Max- Planck- Institute 
Heisenbergstra Be 1 
7000 Stuttgart 80, W. Germany 
(711) 686-0251 
DMS& DTR LIAISON 
Keith Hare 
JCC 

P.O. Box381 
128 West Broadway 
Granville; OH 43023 
(614) 587-0157 
DEC COUNTERPART 
Celeste LaRock 
Nashua, NH 
PAST CHAIR 

PRODUCTIVITY TOOLS COORDINATOR 
Kathy Hombach 
Digital Equipment Corporation 
110 Spit Brook Rd., ZK02-2/R55 
Nashua, NH 03062 
(603) 881-2505 
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STUG INTERFACE 
Dave Martin 

Hughes Aircraft Company 
P.O. Box 92426 
Bldg. Rl, MS C320 
Los Angeles, CA 90009 
(213) 648-9927 

SYMPOSIUM LOGISTICS COORDINATOR 

A1 Rizzuto 
EMC Control, Inc 
P.O. Box 242 
Cockeysville, MD 21030 
(301) 628-8167 

LISP/AI COORDINATOR 
Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

LIBRARY REPRESENTATIVE 

RSX INTERFACE 

SIG TAPE LIBRARIAN 

PUBLIC DOMAN SOFTWARE W/G CHAIR 

Tony Scandora 

Argonne National Laboratory 

CMT 205 

Argonne, IL 60439 
(312) 972-7541 

COUNTERPART EMERITUS 
Bill Segal 
Nashua, NH 

ADA PACKAGES PROJECT 

Kathy Tamer 
Rockwell International 
12214 Lakewood Blvd 
Downey, CA 90241 
(213) 922-3439 

STANDARDS COORDINATOR 
FORTRAN COORDINATOR 
TOOLS INTEGRATION W/G CHAIR 
Jay Wiley 

Bechtel Power Corp 

12400 East Imperial Highway 
Norwalk, CA 90650 
(213) 807-4016 
ASS’T TO CHAIR 
C COORDINATOR 
TEX/LATEX COORDINATOR 
JR Westmoreland 
Custom Software Products 
UTAH Power & Light 
1407 West North Temple 
Annex 6/208 
Salt Lake City, UT 84116 
(801) 535-4784 

RECORDING SECRETARY 

Melodee Westmoreland 
Custom Software Products 
1456 E. Hilda Drive 
Fruit Heights, UT 84037 
(801) 533-2350 

VOLUNTEER COORDINATOR 
VMS INTERFACE 
VAX SIG LIAISON 

Louise Wholey 
Measurex Corp 
1 Results Way 
Cupertino, CA 95014 
(408) 255-1500 x 5571 

HUMAN INTERFACE COORDINATOR 

Jim Wilson 
Pfizer 
QC Division 
P.O. Box 88 
Terre Haute, IN 47808 
(812) 299-2121 x 271 
VICE CHAIR 

CAMPGROUND/SUITE COORDINATOR 
PRE-SYMPOSIUM SEMINAR COORDINATOR 

Terry Medlin 
Survey Sampling, Inc. 

1 Post Road 
Westport, CT 06432 
(203) 255-4200 


MASTERS COORDINATOR 
CL LIAISON 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd, Suite 206 
San Jose, CA 95134 
(408) 434-6636 

APL WORKING GROUP CHAIR 

Bob Van Keuren 
UserWare International, Inc. 

2235 Meyers Ave. 

Escondido, CA 92025 
(619) 745-6006 

WISHLIST COORDINATOR 

Doug Looms 
NYNEX Corporation 
Advanced Technology Lab 
70 West Red Oak Lane 
White Plains, NY 10604 
(914) 683-6388 

WORKING GROUPS COORD. 
CAMPGROUND COORDINATOR 

Joseph Pollizzi, III 
Space Telescope Science Institute 
3700 San Martin Drive 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4901 
PAST CHAIR 

Jim Livingston 

Measurex Automation Systems 
10411 Bubb Rd. 

Cupertino, CA 95014 
(408) 973-1800 x 766 

STEERING COMMITTEE MEMBERS 

Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 
Shava Nerad 
MIT 

77 Mass Ave., W91-219A 
Cambridge, MA 02139 
George Scott 

Computer Sciences Corporation 
304 West Route #38, P.O. Box N 
Moorestown, NJ 08057 
(609) 234-1100 
Ray Strackbein 
Digital Scientific 
23542 Lyon’s Avenue 
Suite 204 

Newhall, CA 91321 
(805) 254-8811 
Barbara Chase 
Hughes Aircraft 
P.O. Box 92426 
Bldg Rl MSC327 
Los Angeles, CA 90009 
(213)606-1601 
Susan Abercrombie 
RDBS, INC. 

48 Malilly Road 
Portland, ME 04103 
(207)772-2837 



LARGE SYSTEMS 

CHAIR 

Leslie Maltz 

Stevens Institute of Technology 
Computer Center 
Hoboken, NJ 07030 
(201) 420-5478 

BITNET LMALTZ@ SITVXB; 

ARPANET SIT. MALTZ<@CU20RCOLUMBIA EDU 
SYMPOSIA COORDINATOR 
Robert G McQueen 
Stevens Institute of Technology 
Computer Center 
Hoboken, NJ 07030 
(201) 420-5454 

BITNET: RMCQUEEN# SITVXB; 

ARPANET SIT. MCQUEEN#CU20R COLUMBIA EDU 
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COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Clyde Poole 

The University of Texas at Austin 
Department of Computer Science 
Taylor Hall 2.124 
Austin, TX 78712-1188 
(512) 471-9551 

ARPANET: ctp@ sally, utex as. edu 
MENU COORDINATOR 
Charles RT. Bacon 
National Institutes of Health 
Building 12B Room 2N207 
Bethesda, MD 20205 
(303) 496-4823 

BITNET: CRB# NIHCUDEC 
HARDWARE COORDINATOR 

Clive Dawson 

Microelectronics & Computer Technology Corp. 

9430 Research Blvd. 

Echelon Bldg. #1, Suite 200 
Austin, TX 78759 
(512) 343-0860 

ARPANET/CSNET: CLIVE @ MCC COM 
LANGUAGES COORDINATOR 
David Edwards 
SRI International 
MS PN 349 
333 Ravenswood Ave 
Menlo Park, CA 94021 
(415) 859-6136 

ASS’T SYMPOSIUM COORDINATOR 

Betsy Ramsey 

American Mathematical Society 
P.O. Box6248 
Providence Rl 02940 
(410) 272-9500 x 295 
ARPANET EWR#) XX LCS. MIT. EDU 
SYSTEM SOFTWARE COORDINATOR 
Carla Rissmeyer 
University of Texas at Austin 
Computation Center 
Austia TX 78712 
(512) 471-3241 

ARPANET CC RISSMEYER@ A20. CC UTEXAS EDU 
SPECIAL PROJECTS COORDINATOR 

E. F. Berkley Shands 
Washington University 
Department of Computer Science 
P.O. Box 1045 
St Louis, MO 63136 
(314) 889-6636 

UUCP: BERKLEY@ WUCS UUCP 
NETWORKS COORDINATOR 
Don Kassebaum 
Computation Center 
University of Texas at Austin 
Austia TX 78712 
(512) 471-3241 

ARPANET CC KASSEBAUM# A20. CC UTEXAS. EDU 

SITE SIG LIAISON 

Gary G Bremer 
Emerson Electric Co. 

Electronics and Space Division 
8100 W. Florissant 
St Louie MO 63136 
(314) 553-4448/4447 
SPECIAL PROJECTS 

INFORMATION CENTERS COORDINATOR 

Ralph M. Bradshaw 
Johnson & Johnson 
Research & Scientific Services 
Management Information Center 
Raritan, NJ 08869-1489 
(201) 685-3434 
DEC COUNTERPARTS 
Dave Braithwaite 
Marlboro, MA 
Rich Whitman 
Marlboro, MA 
Reed Powell 
Marlboro, MA 



! am a 
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MUMPS SIG 

CHAIRMAN 

Mark Berryman 

Plessey Peripheral Systems 

Irvine, CA 

SYMPOSIA COORDINATOR 

Chris Richardson 
Computer Sciences Corp, 

Ridgecrest. CA 

COMMUNICATIONS REPRESENTATIVE 

Mark Hyde 

Advanced Computing Sendees 
DeWitt NY 

NIWSLI I IT R h Dll OR 

Janet Berryman 
12751 Brenan Way 
Santa Ana ('A 
VAX LIAISON 

< ’oyett A. J. 1 >ese 

VA 1)M& S Verification & Dev. Ctr. 
San Francisco, CA 
DI C COUNI IRPARIS 
Beatrice Walt her 
Marl Boro. MA 
1 liane Brown 
Mari Boro. MA 



NUI WORKS SIG 

CHAIRMAN 

Bill Brindley 

Naval Security Croup Command 
(202) 282-0527 

COMMUNICATIONS REPRESENTATIVE 

BoB (iustafson 
Northeast 1 ’tilities 
(202) 005-5082 
NEWSLE ITER EDITOR 
Vickie Hess 
2510 Limestone Lane 
Garland TX 75040 
(211) 195-7252 

SYMPOSIA COORDINATOR 

Sandy Traylor 
Target Systems. Inc. 

(711) 921-0112 

I E C H NOLOO Y COO R D1N ATOR 

Bill Hancock 
(817) 201-2282 

ST ANDARDS COORDINATOR 

Jim EBright 

Softw are Results Corp, 

(Oil) 207-2202 

DEC C OUNT LRPARI 

Carole Creenfield 



OFFICE AUTOMATION SIG 

CHAIR 

Katherine “ Kit" Trimm 
Pivotal Inc 
Tucson. AZ 
(002) 880-5502 
VICE CHAIRMAN 

Ralph Bradshaw 
Johnson and Johnson 
Raritan. NJ 

(201) 085-242 4 

COMMUNICATIONS REPRESENTATIVE 

E. Catherine I Jitamore 
ARA Sendees 
Philadelphia. PA 
(215) 228-2028 

SYMPOSIA COORDINATOR 
Mitch Brown 
GenRad lnd 
Waltham. MA 
(617) 209-4400 x2052 
NEW MEMBER COORDINATOR 
Tricia Cross 

American Mathematical Society 
P.O. Box 6248 
Providence. R102940 
(401) 272-9500 
BOF COORDINATOR 
Ray Kaplan 
PIVOTAL Inc 
Tucson. AZ 
(602) 886-5562 
NEWSLETTER EDITOR 
Therese Le Blanc 
T.M. LeBlanc& Assoc 
Wheeling. IL 
(212) 459-1784 
LIBRARY 

Bob Hassinger 

Libeity Mutual Research Center 
Hopkington, MA 
(617) 425-9061 

OATAPE COORDINATOR 

Mary Jane Boiling 
Foreign Mission Board 
2806 Monument Avenue 
Richmond. VA 22220 
(804) 252-0151 

SYMPOSIA ASSISTANT 
Sal Gianni 
Northeast Utilities 
Hartford CT 

(202) 665-5652 

STORE COORDINATOR 

Mike Jackson 
Air Force Operational 
Test and Evaluation Center 
Kirtland AFB. NM 
(505) 846-5641 

PERSONAL COMPUTER SIG LIAISON 

Cheryl Johnson 
Grinnell College 
Grinnell IA 
(515) 226-2570 

OA LUG COORDINATOR 

Tom Orlowski 

American Council on Education 
1 DuPont Circle (Suite 110) 
Washington. DC 
(202)929-9271 

OA SIG COORDINATOR 

Joe Whatley 
Neilson Media Research 
275 Patricia Avenue 
Dunedia PL22528 
(812)724-5472 
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PERSONAL COMPUTER SIG 

CHAIR 

Barbara Maaskant 
UT Health Science Center 
7702 Floyd Curl Drive 
San Antonio. TX 78284 
(512) 691-7251 

PRO WORKING GROUP C HAIRMAN 

Thomas R Hint/. 

Univ. of Florida 
I FAS Computer Network, 

Bldg 120 

Gainesville, FL 22611 
(904) 292-5180 

DECMATE WORKING GROUP CHAIRMAN 

Cheryl Johnson 
Grinnell College 
P.O. Box 805 
Grinned 1A 50112-0812 
(515) 226-2570 

RAINBOW WORKING GROUP CHAlRMAN 

Lynn J arret t 

Union Tribune Publishing Co. 

Computer Systems 
250 Camino De LaReina 
San Diego. CA 92108 
(619)292-1120 

VAXMATE WORKING GROUP CHAIRMAN 

Fritz Howard 
Eastman Kodak Company 
901 Elmgrove Road D245-LP 
Rochester, NY 14650 
(716) 724-5221 

LIBRARY REPRESENTATIVE 
LIBRARIAN 

Ron S. Hafner 
Hafner and Associates 
P.O. Box 2924 
2499 Wellingham Dr. 

Livermore ('A 94550 
(415)422-2149 

COM M U NIC ATI ON S R E PR E S E N1 ATI VI. 
NEWSLETTER EDITOR 

Kenneth LeFehvre 
Sytek, Inc. 

19 Church St 
P.O. Box 128 
Berea OH 44017 
(216) 242-1612 

NEWSLETTER CONTRIBUTING EDITOR (PRO) 

Gary Rice 
McDonnell Douglas 
5555 Garden Grove Bivd 
MS: K20 77/200 
Westminster. CA 92682 
(714) 952-6582 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Vince Perriello 

Crosfield Composition Systems 
57o Taxter Road 
Elmsford NY 10522 
(914) 592-2600 

SYMPOSIA COORDINATOR 

Rick Eliopoulis 
5258 Vickie Drive 
San I)iego, (‘A 92109 
(619) 225-7867 

SESSION NOTE EDITOR 

Alan Bruns 
Allied Electronics 
401 E. 8th Street 
Fort Worth. TX 76102 
(817) 226-5401 
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CAMPGROUND COORDINATOR 

Jim Wilson 

Ntl Tech Inst for the Deaf 
Rochester Inst of Tech 
P.O. Box 9887 
Rochester, NY14623 
(716) 475-6241 
MEMBERS-AT-LARGE 
Michael Bowers 
Univ. of California 
Animal Science Department 
Davis, CA 95616 
(916) 752-6136 
Theodore Needleman 
Hardcopy Magazine 
Seldin Publishing Inc 
1061 & Melrose Suite D 
Placentia, CA 92670 
Russ Wertenberg 
Sandia National Labs 
Division 8352 
Livermore CA 94550 
(415) 422-2663 
DEC COUNTERPARTS 
PRO 

Lin Olsen 
Maynard, MA 
DECmate 

Louise Brandwein 
Merrimack, NH 
Rainbow & VAXMATE 
Katrina Holman 
Littleton, MA 



RSTS SIG 

CHAIRMAN 

Charles Mustain 

Stark County School system 

Louisville OH 

SYMPOSIA COORDINATOR 

Scott W. Pandorf 
Kittle’s Home Furnishings 
Indianapolis, IN 

ASS’T SYMPOSIA COORDINATOR 
Wef Fleischman 
Software Techniques 
Cypress, CA 

NEWSLETTER EDITOR 

Open 

LIBRARY REPRESENTATIVE 

Susan Abercrombie 
Ventrex Laboratories Inc 
Portland, ME 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Bruce Gaarder 
Macalester College 
St Paul MN 

WISH LISTS COORDINATOR 

Neal E. Goldsmith 
Software Techniques, Inc 
Cypress, CA 

VICE CHAIRMAN 

WISH LISTS & TAPE COPY COORDINATOR 

Philip Hunt 
System Industries 
Milpitas, CA 
EDUSIG LIAISON 

George Wyncott 

Purdue University Computer Center 
W. Lafayette; IN 

RSTS PRODUCT PLANNING COORDINATOR 

Errol E. Ethier 

Information Design and Management Inc 
Shrewsbury, MA 


MEMBERS-AT-LARGE 

Ed Beadel 

Instructional Computer Center 
Oswego, Ny 
Scott Daily 

Great Lakes Chemical Corp. 

W. Lafayette; IN 
Mark Gilmore 
Cal State University 
Long Beach, CA 
Mark Hartman 
Jadtec Computer Group 
Orange; CA 
Jeff Killeen 

Information Design & Management 
Hopedale MA 
Newton J. Munson 
Rochester Institute of Technology 
Rochester, NY 
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RSX SIG 

CHAIRMAN 

Dan Eisner 
Perkin- Elmer Corp; 

Garden Grove CA 
SYMPOSIA COORDINATOR 
Rick Sharpe 
Toledo Edison 
Toledo, OH 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

Hans Jung 
Associated Press 
New York, NY 

COMMUNICATIONS REPRESENTATIVE 
Jay Allen Bennett 
Lear Siegler Rapistan 
Grand Rapids, MI 
NEWSLETTER EDITOR 

MULTI PROCESSORS WORKING GROUP COORDINATOR 

Bruce Mitchell 

Machine Intelligence & Industry Magin 
Byron, MIN 

STORE COORDINATOR 
Jim Hopp 

Carlton Financial Computation 
South Bend, IN 
SESSION NOTE EDITOR 
Burt Janz 

Northern Telecom Ine 
Concord, NH 
LIBRARIAN 

Glenn Everhart 
Mt Holly, NJ 

CAMPGROUND COORDINATOR 
Jerry Ethington 
Prolifix Inc 
Frankfort, KY 
DEC COUNTERPARTS 
Lin Olsen 
Nashua, NH 
Dick Day 
Nashua, NH 

WORKING GROUP COORDINATOR 

Sharon Johnson 
Epidemiology 
Minneapolis, MN 
WORKING GROUP CHAIR 
Evan Kudlajev 
Philadelphia Electric Ca 
Philadelphia, PA 

RSX GROUP CHAIR SOFTWARE CLINIC COORD. 

Roy S; Maull 
U.S. Air Force 
Offutt AFB, NE 

SOFTWARE CLINIC COORDINATOR 
Bruce Zielinski 
RCS 

Moorestown, NJ 


VOLUNTEER COORDINATOR 
Gary Maxwell 
U.S; Geological Survey 
Menlo Park, CA 

SRD WORKING GROUP COORDINATOR 

Bob Turkelson 

Goddard Space Flight Center 
Greenbelt, MD 

ACCOUNTING & PERFORMANCE WORKING GROUP COORD. 

Denny Walthers 
American McGaw 
Irvine, CA 

MENU COORDINATOR 

Ed Cetron 

Center for Biomedical Design 
Salt Lake City, UT 
MEMBERS-AT-LARGE 
Jim McGlinchey 
Warren ton, PA 
Jim Neeland 
Hughes Research Labs 
Malibu, CA 

Anthony E Scandora, Jr. 

Argonne National Laboratory 
Argonne IL 
Ralph Stamerjohn 
Creve Coeur, MO 



RT-11 SIG 

CHAIRMAN 

John T. Rasted 
JTR Associates 
58 Rasted Lane 
Meriden, CT 06450 
(203) 634-1632 
NEWLETTER EDITOR 
COBOL CONTACT 
Bill Leroy 

The Software House Inc 
P.O. Box52661 
Atlanta, GA 30355-0661 
(404) 231-1484 
APL CONTACT 

Doug Bohrer 
Bohrer and Company 
903 Ridge Road, Suite 3 
Wilmette IL 60091 
(312) 251-9449 
MACRO CONTACT 
MAG TAPE EXPERT 
Nick Bourgeois 
NAB Software Services Inc 
P.O. Box20009 
Albuquerque NM 87154 
(505) 298-2346 

TECO CONTACT 

PRODUCT PLANNING CONTACT 

John M. Crowell 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 
(916) 756-3291 
DECNET CONTACT 
Ken Demers 
Adaptive Automation 
5 Science Park 
New Haven, CT 06511 
(203) 786-5050 

RT-11 HARDWARE CONTACT 
C CONTACT 

Carl Lowenstein 
Marine Physical Lab 
Scripps Inst Oc’graphy 
San Diego, CA 92152 
(619) 294-3678 
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WISH LIST CONTACT 
UNIX CONTACT 

Bradford Lubell 
LA. Heart Lab 
UCLA A3-381 CHS 
Los Angeles, CA 90024 
(213) 825-9290 
TSX CONTACT 

Jack Peterson 
Horizon Data Systems 
1899-E Billingsgate Ctr 
Richmond, VA 23233 
(804) 740-9244 

COMMUNICATIONS REPRESENTATIVE 
FMS CONTACT 

Susan Rasted 
Softawre Dynamics Inc. 

85 Barnes Road 
Wallingford, CT 06492 
(203) 265-2226 

SYMPOSIA COORDINATOR 
Ned Rhodes 

Software Systems Group 
1684 Gude Road 
Rockville, MD 20850 
(301) 340-2773 

TAPE COPY DISTRIBUTION 
RT DECUS LIBRARY CONTACT 
Tom Shinal 

General Scientific Corp. 

1684 East Gude Drive 
Rockville, MD 20850 
(301) 340-2773 

PRE-SYMPOSIUM SEMINAR 
RT-11 SUITE MANAGER 
Bruce Sidlinger 
4335 N.W. Loop 410, #209 
San Antonio, TX 78229 

(512) DIG-ITAL 
BASIC CONTACT 

Ed Stevens 
EMDA Inc. 

77 N Oak Knoll #104 
Pasadena, CA 91101 
(818) 795-5991 
CAMAC CONTACT 
J.W. Tippie 
Kinetic Systems, Inc. 

11 Mary Knoll Drive 
Lockport, IL 60441 
(815) 838-0005 
LUG CONTACT 
PERSONAL COMPUTERS 
Bill Walker 

Monsanto Research Corp. 

P.O. Box 32 
Miamisburg, OH 45342 

(513) 865-3557 
FORTRAN CONTACT 

Robert Walraven 
Multiware, Inc. 

139 G. Street, Suite 161 
Davis, CA 95616 
(916) 756-3291 



SITE SIG 

CHAIRMAN 

DMS SIG Liason 
Larry W. Hicks 
Relational Database services 
P.O. Box644 
121 & Main St 
Kemersville NG 27285-0644 
(919) 996-4882 

SYMPOSIA COORDINATOR 

Sue Abercrombie 
48 Malilly Rd. 

Portland, ME 04103 
(207) 772-2837 

SESSION NOTE EDITOR 
LARGE SYSTEMS SIG LIAISON 
Gary Bremer 
Emerson Electric Ca 
8100 W. Florisant 
St Louis, MO. 63136 
(314) 553-4448 
NEWSLETTER EDITOR 
NETWORKS SIG LIAISON 
OA SIG LIAISON 

Gregory N. Brooks 
Washington University 
Behavior Research Labs 
1420 Grattan St 
St Louis, MO. 63104 
(314) 241-7600 ext 257 
LIBRARY COORDINATOR 
RSTS SIG LIAISON 

Timothy Frazer 

Specialized Bicycle Components 
15130 Concord Circle #77 
Morgan Hill CA 95037 
(408) 779-6229 

HARDWARE COORDINATOR 

HMS SIG Liason 

Emily Kitchen 

A R Robins Ca 

1211 Sherwood Ave RT-2 

Richmond, VA 23220 

(804) 257-2925 

COMMUNICATIONS COMMITTEE REPRESENTATIVE 
AI SIG Liason 

Terry G Shannon 
Digital Review 
160 State St 
6 th Floor 
Boston, MA 02109 
(617) 367-7190 

PRE-SYMPOSIA SEMINAR COORDINATOR 
Phillip Ventura 
STAFF MANAGEMENT 
Adam Zavitski 
Simmonds Precision IGD 
3100 Highland Blvd. 

Raleigh. NG 27625 
(919) 872-9500 
MEMBERS-AT-LARGE 
Ann Goergen 
Texas Instruments 
13510 N. Central 
M/S437 

Dallas TX 75266 
(214) 995-4629 
HMS SIG Liason 
RT SIG Liason 

David Hunt 

Lawrence Livermore National Lab 

MS L-230 

P.O. Box808 

Livermore CA 94550 

(802) 656-3190 

Gary Siftar 

Digital Equipment Corporation 
Tulsa OK 


DEC COUNTERPARTS 
Joe Allen 
Stow MA 
Lil Holloway 
Bedford MA 
Susan Porada 
Marlboro, MA 



UNISIG 

CHAIRMAN 

Kurt Reisler 
Hadron Incorporated 
9990 Lee Highway 
Fairfax VA 22030 
(703)359-6100 
decvax! seismo! hadron! klr 
SYMPOSIA COORDINATOR 
Stephen M. Lazarus 
Ford Aerospace MS X-20 
3939 Fabian Way 
Paulo Alta CA 94304 
(415) 852-4203 
ihnp4! fortune! wdll! sml 
SESSION NOTE EDITOR 
Sam Kimery 
716 Second Street NW 
Rochester. MN 55901 
(507) 281-1505 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

James W. Livingston 
Measurex Corporation 
1 Results Way 
Cupertino CA 95014 
(408) 255-1500 x 5556 
ihnp4!decwrl!jwl 

ADMINISTRATIVE DAEMON 

Dorothy Geiger- 
The Wollongong Group 
49 Showers Drive 451 
Mountain View. CA 94040 
(415)948-1003 
ihnp4! decwrl! dgeiger 
TAPE LIBRARIAN 

Carl Lowenstein 
Marine Physical Laboratory 
Scripps Institute of Oc’graphy. P-004 
LaJolla CA 92093 
(619) 294-2678 

(ihnp4i decvart akgurt dcdwest ucbvax) 
! sdcsvax! mplvax! cdl 

USENET LIAISON 

Joe Kelsey 

FlexComm Corporation 
711 Powell Avenue SW 
Renton WA 98055 
allegra! fluke! joe 

STANDARDS COORDINATOR 

Jeff Gilliam 

National Semiconductor- 

2900 Seminconductor Drive MS (2303 

Santa Clara ('A 95051 

(408) 721-3801 

ihnp4! nsc! voder! jeff 

MINISTER WITHOUT PORTFOLIO 

Norman Wilson 
Bell Laboratories, 20529 
600 Mountain Avenue 
Murray Hill NJ 07974 
(201) 582-2842 

(decvax ihnp4)! research! norman 
DEC COUNTERPART 
Roseann Maclean 
Merrimack. NH 
(603) 884-5702 
decvax! mac lean 
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VAX SYSTEMS SIG 

CHAIR (CORE) 

Margaret Knox 
Computation Center 
University of Texas 
Austin, TX 78712 

COMMUNICATIONS REPRESENTATIVE (CORE) 
Don Golden 
Shell Oil Company 
Westhollow Researeh Center 
P.O. Box 1380, Room D2132 
Houston, TX 77001 
SYMPOSIA COORDINATOR 
Jack Cundiff 
Horry- Georgetwon 
P.O. Box 1966 
Conway, SC 29526 

ASS‘T SYMPOSIUM COORD. (CORE) 

David Casey 
Computer Center 
Union College 
Schenectady, NY 12308 
SESSION NOTE EDITOR 
Ken Johnson 

Meridian Technology Corp. 

P.O. Box2006 
St Louis, MO 63011 
NEWSLETTER EDITOR 

Lawrence J. Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
VICE CHAIR 

WORKING GROUP COORDINATOR (CORE) 

Ross W. Miller 
Online Data (Processing Inc 
N637 Hamilton 
Spokane WA 99202 
LIBRARIAN (CORE) 

Joe L Bingham 
Mantech International 
2320 Mill Road 
Alexandria VA 22314 

VAXCLUSTER WORKING GROUP 

Thomas Linscomb 
Computation Center 
University of Texas 
Austin, TX 78712 
CAMPGROUND 
Jane Furze 
3820 West Cochise 
Phoenix, AZ 85064 
NETWORK WORKING GROUP 
Bill Hancock 

Dimension Data Systema Inc 
2510 Limestone Lane 
Garland, TX 75040 
(214) 495-7353 
HISTORIAN 

Jeffrey & Jalbert 
JCC 

P.o. Box 381 
Granville OH 43023 
(614) 587-0157 
ADVISOR 

Art McClinton 
Mitre 

1820 Dolley Madison Blvd 
McLean, VA 22102 


MICROVAX WORKING GROUP 

Ray Kaplan 
Pivotal Inc 
P.O. Box32647 
Tucson, AZ 85715-32647 
(601) 886-5563 

SYSTEM IMPROVEMENT REQUEST 
Mark D. Oakley 
Battelle Columbus Labs 
Room 11-6-008 
505 King Avenue 
Columbus, OH 43201-2669 
MULTIPROCESSOR WORKING GROUP 
Eugene Pal 
U.& Army 

CAORA (ATORrCAT-Q 
Fort Leavenworth, KA 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

Susan Rehse 
Lockheed Missiles 
3251 Hanover Street 
Palo Alte CA 94301-1187 

VAXELN WORKING GROUP 

Bob Robbins 

Array Computer Consultants 
5364 Woodvale Drive 
Sarasota, FL 33582 

REAL TIME/PROCESS CONTROL WORKING GP 
Larry Robertson 
Bear Computer Systems Inc 
5651 Case Avenue 
North Hollywood CA 
LUG COORDINATOR 
HARDWARE WORKING GROUP 
STORE REPRESENTATIVE (CORE) 

David Schmidt 

Management Sciences Associates 
5100 Centre Avenue 
Pittsburgh, PA 15232 
ADVISOR 

A1 Siegel 

Battelle Memorial Institute 
505 King Avenue 
Columbus, OH 43201-2693 

FIELD SERVICE WORKING GROUP 

D. Slater 

Institute for Defense Analysis 
1801 North Beauregard Street 
Alexandria, VA 22314 

LARGE SYSTEMS INTEGRATION WORKING GP 
Osman K Ahmad 
Association of American Railroads 
3140 South Federal Street 
Chicago IL 60616 

VOLUNTEER COORDINATOR 

Elizabeth Bailey 
222 CEB 

Tennessee Valley Authority 
Muscle Shoals, A L 35660 
ADVISOR 

June Baker 

Computer Sciences Corporation 
6565 Arlington Boulevard 
Falls Church, VA 22046 
COMMERCIAL WORKING GROUP 
Bob Boyd 

GE Microelectronics Center 
MS 2 P-04 

Post Office Box 13409 
Research Triangle Park, NC 27709 


SECURITY 

G Douglas Brown 
Sandia Labs 
Division 2644 
P.O. Box5800 
Albuquerque NM 87185 
ADVISOR (CORE) 

Joe Angelico 

US Coast Guard CCGD8(DI) 

Hale Boggs F&D. Bldg 
500 Camp Street 
New Orleans, LA 70130 
VACCLUSTER 

Jim Caddick 
General Datacom 
Strait Turnpike 
Middlebury, CT 06762-1299 
MICROVAX WORKING GROUP 
Barbara Dow-Pleines 
Magic One 

1971 Mount Pleasant Road 
San Jose CA 95148 
(408) 238-0861 

MIGRATION AND HOST DEVELOPMENT 
VAXINTOSH WORKING GROUP 

Jim Downward 
KMS Fusion Incorporated 
3941 Research Park Drive 
Ann Arbor, MI 48106 

REALTIME/PROCESS CONTROL WORKING GP 
Dennis Frayne 
McDonnell Douglas 
5301 Dolsa Avenue 
Huntington Beach, CA 92646 
INTERNALS WORKING GROUP 
Carl E. Friedberg 
In House Systems 
165 William Street 
New York, NY 10038 


SIC-9 



Ask the WOMBAT WIZARD 
Submission Form 

To submit a problem to the WIZARD, please fill out the form below 
and send it to: 

WW Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


Name:_ DECUS Membership No. 

Affiliation:_ 

Address: 


Telephone Number:_ 

Statement of Problem: 


Please following the following guidelines when submitting support 
material: 

1. If you are trying to demonstrate a method or a concept, 
please simplify the procedures, records, and other information 
to the shortest form possible. 

2. Annotate your attachments. Simple comments or hand-written 
notes ("Everything worked until I added this statement.") go a 
long way toward identifying the problem. 

3. Keep an exact copy of what you send. And number the pages 
on both copies. But send everything that is related to your 
question, even remotely. 

4. If you would like a direct response or would like your 
materials returned, please don't forget to include a stamped, 
self-addressed envelope large enough to hold the materials you 
send. 


QU-1 




DATATRIEVE/4GL SIG 

Product Improvement Request Submission Form 


Submittor: DECUS Membership Number: 

Address: Firm: 


Phone: Product or Products: 


How to write a PIR 

A PIR should be directed at 
products. Be sure to give th 
version numbers if applicable, 
would like to see in as complete 
that the PIR editors or software 
in some other software product - 
the software to function. Provi 
and give an example of its use. 
implementation of your request. 


a specific product or group of 
full name of the product(s) and 
Describe the functionality you 
terms as possible. Don't assume 
developers know how it is done 
state specifically how you want 
e justification of your request 
If you can, suggest a possible 


Abstract: (Please limit to one or two short sentences.) 


Description and Examples: (Use additional pages as necessary.) 


[Put my name and address on reverse side, thus:] 


PIR Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


QU-3 




DTR/4GL SIG Volunteer 
1987 Spring Symposia, Nashville 

April 27, 1987 to May 1, 1987 


I would like to volunteer to be a session chair or suite host for the DTR/4GL SIG at the 1987 
Spring DECUS Symposium in Nashville, April 27 to May 1. I can meet in the DTR/4GL Suite at 
5:30pm on Sunday, April 26 for final assignments and instructions. I have indicated my first 
(1) to fifth (5) choices for assignments. 

Name: _ I would like a letter to my boss. 

Phone: _ Boss' name: _ 

DECUS #: _ Boss' address:_ 

Address: 


SESSION CHAIR 


Monday, April 
10 : 00 - 
11 : 00 - 
1 : 00 - 
1:30- 
2 : 00 - 
3:00- 
4:00- 
5:00- 
6 : 00 - 
7:00- 
8 : 00 - 
9:00- 
Tuesday, April 
10 : 00 - 
11 : 00 - 
11:30- 
12:30- 
1:30- 
2:30- 
3:30- 
4:30- 
5:00- 
5:00- 
Wednesday, Apr 
9:00- 
11 : 00 - 
1:30- 
2:30- 
Thursday, Apri 
9:00- 
10 : 00 - 
11 : 00 - 
11:30- 
12:30- 
1 : 00 - 
2 : 00 - 


27 

11:00am 
12:00pm 
1:30pm 
2:00pm 
3:00pm 
4:00pm 
5:00pm 

6:00pm 
7:00pm 
8:00pm 
9:00pm 
10:00pm 
28 

11:00am 
12:30pm 
12:30pm 
1:30pm 
2:30pm 
3:30pm 
4:30pm 
5:00pm 
6:00pm 
6:00pm 
il 29 
10:00am 
12:00pm 
2:30pm 
3:00pm 
1 30 
10:00am 
11:00am 
11:30am 
12:30pm 
1:00pm 
2:00pm 
3:00pm 


Positioning Digital's Fourth Generation Language Products 

Beginner's Guide to DATATRIEVE 

Understanding VAX POWERHOUSE Screen Processing 

POWERHOUSE Hints and Kinks 

VAX DATATRIEVE Status Update and Internals 

Using VAX DATATRIEVE Graphics 

VAX TEAMDATA - End-user Information Management 

VAX RALLY - Fourth Generation Application Development System 

POWERHOUSE Working Group Meeting 

Designing Applications with FMS and DATATRIEVE 

Solving Equations in DATATRIEVE 

Dealing with Hierarchies in VAX DATATRIEVE 

What's Wrong with Fourth Generation Languages 
RMS Based 4GL Development Tools 
The Best of Wombat Magic 

ACCENT R Simultaneous Update and Advanced System Functions 
Using ACCENT R Data Sets with SPSS-X and RMS Indexed Files 
DATATRIEVE Application Design Considerations and Tutorial 
Performance Management for DATATRIEVE Applications 
CDD Optimization for Performance 

Advanced RMS File Design & Tuning for DATATRIEVE Performance 
VAX REPORTER - A Business Reporting Package 

Everything You Wanted to Know About DATATIEVE-11 
VAX DATATRIEVE's Interface into Relational Databases 
Using the DATATRIEVE Call Interface 
DATATRIEVE Call Interface and SPSS-X 

How to Evaluate Fourth Generation Languages 

A Software Developer's Comparison of 4GLs 

Selecting an Application Development 4GL 

Using a 4GL to Enhance Manufacturing Software 

Using SMARTSTAR to Complement DATATRIEVE 

Advanced DATATRIEVE Record Definitions 

Advanced Report Writing Techniques in VAX DATATRIEVE 


QU-5 





|_| 3:00- 4:00pm 

|J 4:00- 5:00pm 

jj 4:00- 6:00pm 

|_j 5:00- 6:00pm 

j_j 6:00- 7:00pm 

Friday, May 1 
|_| 9:00-10:00am 

jj 10:00-10:30am 

L| 10:30-11:00am 

|J 11:00-11:30am 

|_| 11:30-12:30pm 


Writing Menu-driven Systems in VAX DATATRIEVE 

VAX DATATRIEVE Security Using Environment Accounts & ACLs 

VAX RALLY: Advanced Usage 

Adding Functions to VAX DATATRIEVE 

System Management Techniques Using DATATRIEVE 

MANTIS - A Fourth Generation Language for the VAX 
Prototyping in Fourth Generation Languages 
A Comparison of CDD and VAX POWERHOUSE PHD Dictionaries 
DATATRIEVE vs POWERHOUSE QUIZ Report Writers 
Application Development Using INTELLECT/Rdb 


SUITE HOST/HOSTESS 



Monday 


Tuesday 


Wednesday 


Thursday 

Friday 


April 27 


April 28 


April 29 


April 30 

May 1 



i i 

9:00-10:00am 

i i 

9:00-10:00am 

i i 

9:00-10:00am 

| | 9:00-10:00am 

1 1 

10:00-11:00am 

i i 

10:00-11:00am 

i i 

10:00-11:00am 

i i 

10:00-11:00am 

| | 10:00-11:00am 

1 1 

11:00-12:00m 

LI 

11:00-12:00m 

LI 

11:00-12:00m 

i i 

11:00-12:00m 

|J 11:00-12:00m 

1 1 

12:00- 1:00pm 


12:00- 1:00pm 


12:00- 1:00pm 

LI 

12:00- 1:00pm 

j j 12:00- 1:00pm 

1 1 

1:00- 2:00pm 

III 

1:00- 2:00pm 

III 

1:00- 2:00pm 


1:00- 2:00pm 

jj 1:00- 2:00pm 

LI 

2:00- 3:00pm 


2:00- 3:00pm 


2:00- 3:00pm 

III 

2:00- 3:00pm 



3:00- 4:00pm 

III 

3:00- 4:00pm 

III 

3:00- 4:00pm 


3:00- 4:00pm 


III 

4:00- 5:00pm 






4:00- 5:00pm 



Susan Krentz 
NKF Engineering 
12200 Sunrise Valley Drive 
Reston, VA 22091 
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DTR/4GL SIG Spring 1987 PIR Ballot 


DECUS Membership Number: ._____ 

CPU Types (Check all that apply): 

VAXes_ PDP-11's_ DECsystems_ Other (Specify)_ 

Application Types at your site (Check all that apply): 

_ Business EDP/MIS _ Software Development 

_ Education _ Engineering/Scientific 

_ Office Automation _ Service Bureau 

_ Other (Specify)_ 

Number of years using computers:_ Number of years using 4GL r s: _ 

Products Used (Check all that apply): 

_ DTR-11 _ VAX-DTR _ CDD _ TDMS _ DBMS (any) 

_ FMS _ RSI _ Oracle _ Ingress _ Rdb 

_ Others (Specify)_ 


PIR Number 


Points 


PIR Number Points 


Be sure to return your ballot by July 1, 1987 
Return to: 

Philip A. Naecker 
3011 N. Mount Curve Ave. 
Altadena, CA 91001 
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H M S 


S I G 


HARDWARE SUBMISSION FORM — A SIG INFORMATION INTERCHANGE 
Message __ 



Contact 
Name _ 

Address 


Telephone 


Type of equipment 


SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES. 

SEND TO: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

Boston, MA 02199 


QU-9 





IAS WHIMS 


WHAT: (Describe your WHIM) (Please print or type 


WHY: (Describe the reason for the WHIM 


HOW: (Make any suggestions for a possible implementation 


Name: 

Please mail to: j 

Company: 

Kathleen M. Anderson j 


EATON Information Management j 


Systems Division j 


2017 Cunningham Drive | 

Address: 

Suite 208 j 


Hampton, Virginia 23666 j 


Phone: (804) 326-1941 | 

Phone: 



OU-11 


















IAS SIG MEMBERSHIP SURVEY 


Name: 
Address: 


Telephone: 


Current Hardware: (Include number and type of processors, mass 

storage devices, communication devices, etc.) 


IAS Release: (Indicate release of IAS under which these systems 
are running) 


Software: (Indicate software running on these systems, i.e., 
DECNET, Decus C, etc.) 


Application: (Indicate the type of application running on the 
system.) 


Contacts: Would you be willing to be placed on a list of contacts? 
If so, what areas? 


Features: Do you have any features which you would like IAS to include? 


Any further comments? 
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IAS SIG MEMBERSHIP SURVEY 


fold 


Frank R. Borger 
Michael Reese Medical Center 
Dept of Radiation Therapy 
Lake Shore Drive at 31st Street 
Chicago II 60616 


QU-14 





Languages &z Tools SIG 
MASTERS APPLICATION 

Name: __ Title_ 

Company:______ 

Address:_ 


Network Address: 


Phone: ( 


) 


The Languages & Tools SIG has established the designation “LANGUAGES AND TOOLS MASTER”, to be applied 
to selected, qualified people willing to share their expertise in various subjects with others. Masters are people who 
are knowledgeable enough in one or more languages and tools to be comfortable answering questions about them. 
The qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published 
as a Master, and a willingness to volunteer services in different ways. Each product may have several Masters, and 
there is an overall Masters Coordinator who sits on the L&T Steering Committee. 

Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products within their 
competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) as available for 
occasional telephone consultation, Masters may act as ‘Doctors’ at Symposium Clinics, present Symposium sessions 
on the products of interest to them, field test products, interact with DEC product managers when appropriate, 
or act as a reference for a product for Digital salespeople. Especially on mature products, the SIG is anxious for 
knowledgeable users to offer product tutorial sessions at Symposia, and Masters can be of great help here. At 

Symposia, Masters will wear an identifying button bearing the legend “Ask Me About.” and the name of the 

language or tool in which he/she specializes. 

If you’d like to serve as an L&T Master, please check the products on which you are able to answer questions: 



Fortran 


Ada 1 


Scan 


C 

' 

APL 


Bliss 



Pascal 


LSE 


DTM 


PCA 

— 

MMS 


CMS 


_j 

Debug 


TPU 

_ 

EVE 

_| 

EDT 

_j 

TECO 


PL/1 


VAX Notes 
Runoff & DSR 


Briefly describe your experience with those you checked. 


How long have you held your present position?_ 

Are you able to attend at least one symposium each year?_ 

Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. As a 
Master, your name and telephone number will be published in the Masters Directory, and users will call on you for 
limited help from time to time. Please check, below, any additional activities you might do: 

| | Field-test new versions of your product at your work site. 

|~ | Provide feedback on the product when needed by its DEC product manager. 

| | Act as a reference for the product at the request of Digital Sales or Marketing people. 


Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2860 Zanker Road, Suite 206, San 
Jose, CA 95134. 


*Ada is a trademark of the DoD 
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Languages &: Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:____Title_ 

Company: ________ 

Address:___ 


-—-Phone: ( ) 

Network Address:__ 


The Languages & Tools SIG is principally concerned with the DEC software products listed below. If your request 
directly involves one of these products, please check which one (if you have more than one request, please use a 
separate form for each): 


Fortran 

Pascal 

Debug 


Ada 1 

LSE 

TPU 


Scan 

DTM 

EVE 


C 

PCA 

EDT 


APL 

MMS 

TECO 


Bliss 

CMS 

PL/1 


VAX Notes 
Runoff & DSR 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language & Tools SIG topics it concerns: 


— 

Newsletter 

Masters Program 

— 

Symposium Sessions 

Working Group Activities 

— 

Pre-Symposium Seminars 
Session Notes 

— 

Information Folder 

Other L&T SIG topic: 

— 

SIG Tape 

— 

DECUS Store Item 


Should one of the L&T Working Groups see your request? Check which: 


_ 

Configuration Management 


TECO 



Public Domain Software 


Macro 



Project Management 


Fortran 



Desk Top Publishing 


Pascal 



Tools Integration 


C 



Multi-Language Graphics 





PDP-11 Languages & Tools 
Multi-Language Data Type Compatibility 
Programmer Productivity Measurement 
Synchronizing New Releases 
Language and Tool Documentation 


Wish List Request—brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples._ 


Mail to: Sam Whidden, L&T SIG Chair, American Mathematical Society, P.O. Box 6248, Providence, RI 02940. 
1 Ada is a trademark of the DoD QU— 17 
















DflTHGRflm 


DATAGRAMS are short messages, comments, requests, or answers 
that are published in NETwords. Please Till in the sections below 
and send the DATAGRAM to: 

Vickie Hess 
NETWords Editor 
2510 Limestone Ln. 

Garland, Tx. 75040 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what ■*?_ 

Signature:_Date:_ 


QU-19 




Place j 
Stamp | 
Here j 


Vickie Hess 
NETWords Editor 
2510 Limestone Ln. 
Garland, Tx. 75040 


Fold Here 


QU-20 




Page 1 of 


OFFICE AUTOMATION SIG 

SYSTEM IMPROVEMENT REQUEST SUBMISSION FORM 


Name __ Address 

Firm _ _ 

Telephone_ 


INSTRUCTIONS: System Improvement Requests (SIR) can be either hardware of 

software; please check the category addressed by this SIR. Under ABSTRACT, give a 
brief definition of the capability you would like. In the DESCRIPTION section, give a 
detailed description and examples of what you want. Be specific; don’t assume that we 
know how other products function. Justify the usefulness of the capability and give an 
example of its use. 


HARDWARE IMPROVEMENT 


SOFTWARE IMPROVEMENT 


DECmate_ ALL-IN-1 _ WPS_ 

PRO-Series_ CP/M (DECmate)_ P/OS _ 

Rainbow_ CP/M (Rainbow)_ MS-DOS 

Other Other 


ABSTRACT 



DESCRIPTION 





E. Catherine Ditamore 
ARA Services 
Corp MIS 
The ARA Tower 
1101 Market Street 
Philadelphia, Pa. 19107 
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DECmate Wish List Ballot 


Use this ballot to show which items on the DECmate Wish List are most important to 
you. Put the number of the most important item on the list in space 1, the next most 
in space 2, etc. 


1 . 

10. 

19. 

28. 

37 

2. 

11. 

20. 

29. 

38 

3. 

12. 

21. 

30. 

39 

4. 

13. 

22. 

31. 

40 

5. 

14. 

23. 

32. 

41 

6. 

15. 

24. 

33. 

42 

7. 

16. 

25. 

34. 

43 

8. 

17. 

26. 

35. 

44 

9. 

18. 

27. 

36. 

45 


Please add the following to the wish list: 


Comments: 


Name:_ 

Company: 

Address: 


Work Phone:_ 

Home Phone:_ 

Return Ballot to: 


Cheryl Johnson 

DECUS DECmate Working Group 

Grinnell College 

P.0. Box 805 

Grinnell, IA 50112-0810 
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Professional Wish List Ballot 


Use this ballot to show which items on the Professional Wish List are most important 
to you. Put the number of the most important item on the list in space 1, the next 
most in space 2 , etc. 


1. 

10. 

19. 

28. 

37 

2. 

11. 

20. 

29. 

38 

3. 

12. 

21. 

30. 

39 

4. 

13. 

22. 

31. 

40 

5. 

14. 

23. 

32. 

41 

6. 

15. 

24. 

33. 

42 

7. 

16. 

25. 

34. 

43 

8. 

17. 

26. 

35. 

44 

9. 

18. 

27. 

36. 

45 

add 

the following to 

the wish list: 




Comments: 


Name:_ 

Company: 
Address: 


Work. Phone:_ 

Home Phone:_ 

Return Ballot to: 


Thomas Hintz 

DECUS Professional Working Group 
University of Florida 
IFAS Computer Network 
1022 McCarty Hall 
Gainesville, FL 32611 
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Rainbow Wish List Ballot 

Use this ballot to show which items on the Rainbow Wish List are most important to you. Put 
the number of the most important item on the list in space 1, the next most in space 2 , 
etc. 


1 . 

10. 

19. 

28. 

37 

2. 

11. 

20. 

29. 

_ 38 

3. 

12. 

21. 

30. 

_ 39 

4. 

13. 

22. 

31. 

_ 40 

5. 

14. 

23. 

32. 

_ 41 

6. 

15. 

24. 

33. 

_ 42 

7. 

16. 

25. 

34. 

_ 43 

8. 

17. 

26. 

35. 

_ 44 

9. 

18. 

27. 

36. 

_ 45 

add the 

following to 

the wish list: 




Comments: 


Name:_ 

Company: 
Address: 


Work Phone:_ 

Home Phone:_ 

Return Ballot to: 


Lynn Jarrett 

DECUS PC Sig Rainbow Working Group Chairman 

Union Tribune Publishing 

P.0. Box 191 

San Diego, CA 92108 
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PRO/SIGHT GRAPHICS CONTEST 

SPRING 1987 DECUS 

<< ENTRY FORM > > 


Name _ 

Address 


City _ State _ Zip 

Phone (_)_ 


Image/Script Title _ 

Category Number _ File Name _ 

*************************************************************** 

NOTE: If diskette(s) are to be returned to the author, please 
send entries with self-addressed AND stamped envelope. Provide 
sufficient postage and packing material. The PC SIG will not 
be responsible for damage to diskette or entries not returned 
because of insufficient postage. Returned diskette will con¬ 
tain some .GID files from the contest if requested, so ORIGINAL 
IMAGE MAY BE DELETED to provide space. 

If multiple entries are submitted, xerox and fill out an entry 
form for each submission. Multiple entries may be sent on a 
single diskette. 




PC POSTSCRIPT 

PC Postscripts are short requests, comments and responses to be published in the Postscript 
Section of the PC SIG Newsletter. Please respond to the following: 

_ Y/N This is a reply to a previous Postscript._Issue Mo. _ No. 


Title: 


Message: 


Name: 

Address: 


Phone: (_) _-_ 

Signature: _ Date. 
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DECUS PERSONAL COMPUTER SIG QUESTIONNAIRE 


General: 

I would like information on ___ 

I would like to see an article 

in the newsletter on ___ 

I would like to see a symposium 

session on ___ 

I am willing to write an article(s) on: __ 

I am willing to be contacted by PC SIG members by telephone to give 

assistance/advice on: ___ 

Phone number to call: Area Code (_) # _ Times _ 

I attend DECUS Symposiums : _always _Sometimes _never 

I expect to attend these symposiums _Fall 85 _Spring 86 _Fall 86 

I use/own: _Rainbow(s) _PRO(s) _DECmate(s) _Robin _Other_ 

I use the machine(s) checked above: _at work _at home _both 

If a work, total number of DEC PC's at your site: _ 

I also use: _VAX _IBM or other mainframe _IBM/other PC 

Type of use: _business _educational g overnment _other_ 

Primary Operating System: _MS-DOS _CP/M _both equally 

P/OS UNIX other_ 


I belong to a local DEC PC Group: _yes _no 

There is a user group in my geographic area: _yes _no 

I would like information on starting a user group: _yes 

I use a modem: _often _reluctantly _never 

_for work _for pleasure _both 

Here is information on he DEC PC User Group I belong to or know of: 

Name of Group _ 

Name of Contact Person _ 

Address _ 


Telephone (_)_ 

Supports _Rainbow _PRO _DECmate _Robin _LUG _Gold Key 

Here is a DEC oriented bulletin board not on your list, or new information on a 
1isted board: 


Name of Board _ 

Full name of Sysop _ 

Address if known _ 

City and State _ 

Telephone Number _ 

Other Info: _ 

Supports _Rainbow _PRO _DECmate _Robin 


The subjects of greatest 

_word processing 

_spreadsheet s 

_database 

_graphics 

_communications 

_programming 

_software reviews 

technical articles 


ineres to me are: 

_project management 

_specia1ized vertica1 

_(type)_ 

_Other:_ 

_Rainbow 

_PRO 

_DECmate 

Robin 


sof tware 
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_DEC Gossip and Nows _Other:_ 

Zf Z had It to do over again, Z: 

_wou1d_buy an other D EC R ainbow/P RQ/DECmate (circle one) 

_might buy another Rainbow/PRO/DECmate if it was a bargain (cirole one_ 

_wou 1 d no t buy another Rainbow/PRQ/DEC mate (circ le o ne) 

Will yo u cont inue to su bscribe at j the n e w price of $35/ ye ar?_yes _no 

Feel free to enclose another page(s) with comments! 

Do you f eel tha t le aving th e price s out of the newsletter 
_is appropriate 

_is very_annoying______ 

_make s the a rticles_1ess useful_ 

Do you feel that_Decus shouldjreyise its (antj )commercial ism policy? 

_yes 

no 


Name_ 

Compa ny_ 

Address_ 

Clty/ST/ZZP_ 

Work Phone (_) 

Home Phone (_) 


Return to; 

Barbara Maaskant 
Computing Resources 
The University oi Texas Health 
Science Center at San Antonio. 
7703 Floyd Curl Drive 
San Antonio, Texas 78284 


fold here, flap under• 


stamp 


Barbara Maaskant 
Computing Resources 
The University of Texas Health 
Science Center at San Antonio 
7703 Floyd Curl Drive 
San Antonio, Texas 78284 
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Information Resource Sign Up Sheet 
Personal Computing Special Interest Group - PC SIG 

Are you willing to be an information resource for other PC SIG members? Placing your name 
on the Contact List means you are willing to answer questions within the span of a brief 
telephone conversation. A Contact is not expected to be a consultant Please Register 
below. Your name and phone number (including restrictions) will be posted in the PC SIG 
Newsletter. 

First Name:_ Last Name:_ 

Address:_ 

City:_ State:_ ZIP:_ 

Phone: (_) _-_ 

Areas of Expertise:_ 


Suggestions for Additional Services the SIG can Provide: 


Barbara A. Maaskant 
UTHSCSA Computing Resources 
7703 Floyd Curl Drive 
San Antonio, Texas 78216 
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PERSONAL COMPUTING SPECIAL INTEREST GROUP 
VOLUNTEER FORM 


Name_ 

Company_ 

Address_ 

City_State. 

Telephone_ 

What special talents do you have?— 


Zip Code. 


When do you attend symposia? 

D Always D Occasional Attendance 

D East Coast Only 0 Other (please specify) 

□ West Coast Only - 


Please check if you are interested in helping with any of the following activities: 


Symposia Related Activities: 

□ Session Chairs- □ Articles for UpdateUaily 

□ Campground Volunteer_ □ Write letters of appreciation 

□ Suite Volunteer- □ Equipment Setup 

□ DECUS Store- 

□ Software Clinic- 

□ Panels- (indicate topics)- 

□ Technical Sessions- (indicate topics)- 


Ongoing SIG Activities: 

□ Working Groups_ (indicate which groups) 

D Newsletter___ 

□ Public Domain Software Project_ 

0 Write Software for Special SIG Needs_ 

Other SIG Activities: (please specify)_— 


Do you wish to see the PCSIG undertake any activities which it is not currently doing? 
Please specify. 


Would you be willing to coordinate the activity you have listed above? D Yes D No 


Thank you 
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PAGESWAPPER * May 1987 - Volume 8 Number 10 

INPUT/OUTPUT Submission Form 

INPUT/OUTPUT Submission Form 

A SIG Information Interchange 
Please reprint in the next issue of the Pageswapper 

If this is a reply to a previous I/O, which number? _ 

Caption:____ 

Message:__ 


Contact: 

Name _ 

Address 


Telephone _ 

Signature_Date_ 

Mail this form to: Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station, Cambridge, MA 02139*0901, USA 

To register for on-line submission, dial (in the United States): 
(617) 262-6830 and . log in with the username PAGESWAPPER. 
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PAGESWAPPER “ May 1987 - Volume 8 Number 10 
INPUT/OUTPUT Submission Form 

Tear out or photocopy reverse to submit an I/O item 


Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139«0901 
USA 


QU-4 0 



PAGESWAPPER ~ May 1987 - Volume 8 Number 10 
System Improvement Request Submission Form 


System Improvement Request Submission form 


Submittor: 
Address: 


How to write an SIR: 

Describe the capability you would like to see available on VAX 
systems. Be as specific as possible. Please don't assume we 
know how it's done on the XYZ system. Justify why the capability 
would be useful and give an example of its use. If you wish, 
suggest a possible implementation of your request. 

Abstract TPrease~rfmrt~to ~four 1 fnesTT - ----- - 


Description and examples (use additional pages if required) 


Page 1 of 

Firm: 

Phone: 
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PAGESWAPPER - May 1987 - Volume 8 Number 10 
System Improvement Request Submission Form 


Tear out or photocopy reverse to submit an SIR 


Mark D. Oakley 

Battelle Columbus Division 

Room 11-6-008 

505 King Avenue 

Columbus, Ohio 43201-2369 

USA 
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PAGESWAPPER - May 1987 - Volume 8 Number 10 
VAX/VMS V5.0 Tailoring Survey Form 


VAX/VMS V5.0 Tailoring Survey Form 


1) Is it important that you be able to remove the 
machine-specific files not used for your system 
(approx. 500 block savings) from your system disk? 


2) Is it important that you be able to remove the 
bus9specific files not required for your system 

(approx. 400 block savings) from your system disk? 


3) Is it important that you are able to remove the cluster 
support (approx. 1000 block savings) from your system 
disk? 


4) To what degree should tailoring protect the user from 
himself? (For example, if you're tailoring an RA60 
system disk booted on a MicroVAX II, VMS could check 
that you don't delete the Qbus drivers. However, 
there's no way to tell if this RA60 is also used in 
your lab on a VAX 11/780 and therefore the MASSBUS 
drivers shouldn't be deleted.) Is it necessary for 
tailoring to do any checking? 


5) Do you have any other suggestions for tailoring? 


Mail completed form 


tedttRWt Corporation, 


to: VMS Product Management, 

ZKO142/C07, 110 Spit Brook Road, 


Digital 

Nashua, 
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PAGESWAPPER « May 1987 - Volume 8 Number 10 
VAX/VMS V5.0 Tailoring Survey Form 

Tear out or photocopy reverse to respond to the survey. 


fold here 


stamp 


VMS Product Management 

Digital Equipment Corporation 

ZKO142/C07 

110 Spit Brook Road 

Nashua, NH 03062*2698 


fold here 
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Printed in the U.S.A. 


“The Following are Trademarks of Digital Equipment Corporation” 


AI 

LA50 (etal) 

RX02 (etal) 

ALL-IN-1 

LN03 

TK50 

CDD 

Micro 

TOPS-10 

DATATRIEVE 

MicroVAX II 

TOPS-20 

DEC 

Micro VMS 

TOPS-10/20 

DECnet 

PDP-11 

ULTRIX 

DECserver 

PDP-11/24 (etal) 

ULTRIX-32 

DECUS 

RD-53 

VAX 

Digital 

Rdb 

VAX C 

HSC-50 

RMS 

VAX/VMS 

IAS 

RSTS 

VAXstation 

KA 

RSTS/E 

VT220 

KI 

RSX 

VT240 

KL 

RSX-11M 

VMS 

KS 

RT-11 
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Equipment Corporation or DECUS. Digital Equipment Corporation and DECUS assume no responsibility for any errors that may 
appear in this document. 
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